From nobody Tue Mar 2 16:47:05 2021 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 BCF6D3A155D; Tue, 2 Mar 2021 16:47:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roger Marshall via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Cc: ecrit-chairs@ietf.org, ecrit@ietf.org, iesg-secretary@ietf.org, roger.marshall@comtechtel.com Message-ID: <161473242368.18398.6525221635860064032@ietfa.amsl.com> Date: Tue, 02 Mar 2021 16:47:03 -0800 Archived-At: Subject: [Ecrit] Publication has been requested for draft-ietf-ecrit-location-profile-registry-policy-01 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, 03 Mar 2021 00:47:04 -0000 Roger Marshall has requested publication of draft-ietf-ecrit-location-profile-registry-policy-01 as Proposed Standard on behalf of the ECRIT working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ecrit-location-profile-registry-policy/ From nobody Tue Mar 2 18:34:55 2021 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 82A6F3A16F3; Tue, 2 Mar 2021 18:34:52 -0800 (PST) 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: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-ecrit-location-profile-registry-policy@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, roger.marshall@comtechtel.com, superuser@gmail.com Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <161473889244.18235.8269882841413417421@ietfa.amsl.com> Date: Tue, 02 Mar 2021 18:34:52 -0800 Archived-At: Subject: [Ecrit] Last Call: (Changing the LoST Location Profile Registry Policy) to Proposed Standard 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, 03 Mar 2021 02:34:53 -0000 The IESG has received a request from the Emergency Context Resolution with Internet Technologies WG (ecrit) to consider the following document: - 'Changing the LoST Location Profile Registry Policy' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-03-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document changes the policy of the Location-to-Service Translation (LoST) Location Profile registry established by RFC5222 from Standards Action to Specification Required. This allows standards development organizations (SDOs) other than the IETF to add new values. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ecrit-location-profile-registry-policy/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Mar 16 09:34:30 2021 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 292B13A1355; Tue, 16 Mar 2021 09:34:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org, ecrit@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161591246412.5771.17798271339560020312@ietfa.amsl.com> Reply-To: Linda Dunbar Date: Tue, 16 Mar 2021 09:34:24 -0700 Archived-At: Subject: [Ecrit] Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 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, 16 Mar 2021 16:34:24 -0000 Reviewer: Linda Dunbar Review result: Not Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document doesn't seem to be complete. The document claims that it changes the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or add values. But which SDOs are allowed? Are there any procedures to identify which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Best Regards, Linda Dunbar From nobody Tue Mar 16 09:46:15 2021 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 7E8543A1397; Tue, 16 Mar 2021 09:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=gmail.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 yeu2rGHPflVv; Tue, 16 Mar 2021 09:46:10 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 4563A3A136F; Tue, 16 Mar 2021 09:46:07 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id a15so18573918vsi.7; Tue, 16 Mar 2021 09:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7C0ttR8QuAiy0YEW0QIA2O5At4LSxXSwBz4eVQZRWhQ=; b=VetK5BZYAKalt1jBojPQ5tKKZKuGkdKRn4i+FwibhnVQozZbxMWvZTWN/6Bbg+aLDT /oL5nbRIbQMmtMX0gJU4I25TYQOhTnTyN6gQ6Bj97fV7PxAcF04pdFEsIOL3eIDMV91b q/a1vxTTtWjLP3HPXdsDyziVrzxElxjPUzcBV0hYdW8SsRpOBrSCCxvvdrbH61II3h+A zDM6nkYJykM+C7OdbrZeKdW/77SVGluoO+5mikP8Jku2V8OEBSpxtYZUJrR+578jk5GM 0vhGnemTG77mYn0BGtpwDf1l77Yaoa3yzdF4X3V6KNUoeMe8QwdylgtRAENnE3l0IT/P E3GA== 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=7C0ttR8QuAiy0YEW0QIA2O5At4LSxXSwBz4eVQZRWhQ=; b=NGOwRYRstTqSvYX+/2RDMvTaJ/Ho/yA5jE8/Z1tB2rWj4TjHMEzO3B17BukZvFWRT3 E9KArRrdPyI5qNrrwz2nX590TsEdqiO7pe5BYQrgIKwWh01dn+/qbcBZENzzm9zeOPsj lg0vN2KvCDbGdUtQAp1bWgw1v/RaS88VyjnxlQJI2wuUFQve0hJENJ07FxKq8TMH7gbO /XPBmFfhqKZKaF7oafTtGo1KySHWSieIUhCb76NY1/6wyfOTzMNSm3Nk8dlyxbyWH3Of ApTRb7J2gyQ4xERWDnoSdMCW/kLoI2SZvHcH8XnaIj/pEpvCkM1fBDdoVjtRM1sX5wQs hDlA== X-Gm-Message-State: AOAM531nixisZAic9zRxHAZ0nt3apxwCqGU26tXvL0hmqi6b+JdIrKw3 u3KFLWYmCirczHzToZPWLkcSlwfFbr07H3n44as= X-Google-Smtp-Source: ABdhPJzUegZfolxQT3jPpVjX7ajZC7YU+G6fDa4ciUzCXd2ZpQ32fShXFqH1OsKEGmhy5CKV5+Dbhva3D5XQUaZCJpk= X-Received: by 2002:a67:f04d:: with SMTP id q13mr623997vsm.40.1615913165434; Tue, 16 Mar 2021 09:46:05 -0700 (PDT) MIME-Version: 1.0 References: <161591246412.5771.17798271339560020312@ietfa.amsl.com> In-Reply-To: <161591246412.5771.17798271339560020312@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Tue, 16 Mar 2021 09:45:54 -0700 Message-ID: To: Linda Dunbar Cc: secdir@ietf.org, draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org, ecrit@ietf.org, last-call@ietf.org Content-Type: multipart/alternative; boundary="00000000000036b3d605bdaa1ace" Archived-At: Subject: Re: [Ecrit] Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 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, 16 Mar 2021 16:46:12 -0000 --00000000000036b3d605bdaa1ace Content-Type: text/plain; charset="UTF-8" Hi Linda, thanks for your review. Comments below. On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker < noreply@ietf.org> wrote: > This document doesn't seem to be complete. The document claims that it > changes > the policy of the Location-to-Service Translation (LoST) Location Profile > registry from Standards Action to Specification Required, but it doesn't > specify what is the new procedure. It says allowing other SDOs to change > or > add values. But which SDOs are allowed? Are there any procedures to > identify > which SDOs are legitimate? can any organizations, say XYZ, change, add or > delete the values? > Specification Required is defined in RFC 8162. The IESG will be tasked with appointing a designated expert (DE) to review registration requests against the published specification. The DE will have discretion to determine whether an application should be accepted. The document contains no guidance about particular SDOs, so the DE is left to decide whether to factor the source into the approval or rejection of the request. So any SDO can make a request to update the registry. The DE makes the call about "legitimate". -MSK --00000000000036b3d605bdaa1ace Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Linda, thanks for your review.=C2=A0 C= omments below.

On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatrac= ker <noreply@ietf.org> wrote:=
This document d= oesn't seem to be complete. The document claims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn'= t
specify what is the new procedure.=C2=A0 It says allowing other SDOs to cha= nge or
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

Specification Requir= ed is defined in RFC 8162.=C2=A0 The IESG will be tasked with appointing a = designated expert (DE) to review registration requests against the publishe= d specification.=C2=A0 The DE will have discretion to determine whether an = application should be accepted.=C2=A0 The document contains no guidance abo= ut particular SDOs, so the DE is left to decide whether to factor the sourc= e into the approval or rejection of the request.

S= o any SDO can make a request to update the registry.=C2=A0 The DE makes the= call about "legitimate".

-MSK
=
--00000000000036b3d605bdaa1ace-- From nobody Tue Mar 16 10:13:00 2021 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 C218C3A1486; Tue, 16 Mar 2021 10:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=futurewei.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 d9-uAjKA6XCU; Tue, 16 Mar 2021 10:12:57 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2093.outbound.protection.outlook.com [40.107.92.93]) (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 A9A723A1485; Tue, 16 Mar 2021 10:12:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CRpCOv9CHSzVQw1i4+5j1/C96JAmedtvecRoxLq+0BOV3niqepetJvqUxAKYE6Dk7PJKhuGNlo2OzwyUP7KAiq1sgrflfMpHHQR+fTARxWbNfdXf5XqcIfxULMKgd34fJPiIheQpKHv3F45MC2QAplr7zISFY1Yiics5rDPeUq2lyLNT7HNSDdo6CB8QegPWuKcDjawHDVYz+l1VA2zHBijL/hDMkq5GhSuRDIrRuV4sIZrUaMfBzi7rSUs4maSgYItPOg/NHL+jP+5TZ9n8MwSojSizpBEjeu3fQXlklfRrcMZzR8lRinHFEDiaDhcrxI+fuEFjYJJVj/f0deRwWg== 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=1respnJ+oo6qBo94fNKNE1AbNb4bHHnwF+nEXVKv2yc=; b=MAK/NNNU9rO1bru4FbzZIEq8fUnQj3ZvcjLg/k4ZJqTJfPeDAaxK4Pb2RetERcuZlvcKT9537gc2KklYXucD+uYX6TSrxYs2j0ybLG8A2Vn/wkplMrJP3/30SA+Xpwnaz1INfi9DBImjIUdf/oov2cz1KvpUL7t0UeMDYq6D6c5S86JHCtJWdRd4Ly2F3BcrLgVSQqNfc5+2qdqf8noH+CKse5y+C8rCoB9BD7JWKKt5dTp1hCcfBHkVejnBaYrzhyvcHzL4W3k167V6uqfUCB2dzhIb/RFwrN6mKUUX42DFTTPOpgvgaInMhwUJ7hDVsBVehLA6pIW6GIvG2zScUQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1respnJ+oo6qBo94fNKNE1AbNb4bHHnwF+nEXVKv2yc=; b=CO6Z4R5hfOgLmHNk3ZsfbixbX0hKJLaP4Fr1zmSqc4uXBFDpJONjvcvAEfKPV6ahIMH/fOztgeogna6DrtbzCGTlihqYzktL9dhDU+sDnNoQiZRDqnQTrneF+2WoAZz+WDAjb5sncwXm8tVlInuEy4j/1/B1uf3cyIPGVxloT+c= Received: from SN6PR13MB2334.namprd13.prod.outlook.com (2603:10b6:805:55::16) by SN6PR13MB4287.namprd13.prod.outlook.com (2603:10b6:805:ea::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.11; Tue, 16 Mar 2021 17:12:53 +0000 Received: from SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::3050:546b:c47:a42a]) by SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::3050:546b:c47:a42a%6]) with mapi id 15.20.3955.013; Tue, 16 Mar 2021 17:12:53 +0000 From: Linda Dunbar To: "Murray S. Kucherawy" CC: "secdir@ietf.org" , "draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org" , "ecrit@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 Thread-Index: AQHXGoPdDsBYgrP5+UeHrEXFqCO1yqqG2bew Date: Tue, 16 Mar 2021 17:12:52 +0000 Message-ID: References: <161591246412.5771.17798271339560020312@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [72.180.73.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f592f03e-b4b0-4b34-ce58-08d8e89ebc0f x-ms-traffictypediagnostic: SN6PR13MB4287: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fnjt1G13/+xAkJRbHhe8Tnzji+zjMFWZaLqcWQqwIHaeibzE16J6To4O/bPNMycy+e0//yPUKiH6lgdKK2s/Bz6iSeCUq4+Et8hTJdJZjVuXzRNoYEr6s/6HqbBFUmk5j2qc5hmO0/8faUqTb43weu5bGupWwpoUJt4CH8ez7I1fVMUbbhKoAw8wUhwH+v84dtqCKo/nRb9oHn84hjxb1inc8DdEPtYerYnKKYZVzhUEuhjRbyMlER3ZyGodErAuUr9PrANO3ADgovhfgN3eGoQOOEzmiMf05OT01t5z3DrAStnBjcnl178vglay/IyD2dg0YcarfwP0KFwDafm/eoNcJg2G5C3sLS0WpCuGqN8DBmYreAiqSQuLaMLij0KPG7AEz9wLU9p1MDiIiiOQiK9YghECV4hkLUPK+sJRax+P94KnSBLtVBm5BqgjIlkczYGe0NJ8N89Ty2sALkhWZlLKKGEm291dKsjHCDYEAlQFEehTrply2PhJkqhEzwTWFg1Bn5+Vyjd6CmjYmTrZAncWR1DW8UlO4UD3/hMUND6ux8H4mpmuWajC5E3xNm6/ x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR13MB2334.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(376002)(366004)(39840400004)(136003)(52536014)(33656002)(55016002)(64756008)(76116006)(6506007)(26005)(86362001)(8676002)(4326008)(71200400001)(44832011)(6916009)(83380400001)(316002)(9686003)(186003)(66946007)(8936002)(66556008)(66446008)(5660300002)(478600001)(7696005)(54906003)(66476007)(2906002)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?S2toOHhBSmJXZEJKeDZSazdjZE96Y0lOVXhsV1ZacVhKQ3VwbDFOWlpkdlZQ?= =?utf-8?B?UnZBejJ2eVNQVy9GamN4ZEp0cTdVeVBtaSswNzBkZkdpeWRJdU9iREt4bU1O?= =?utf-8?B?WGJoSURFUEtsZGdNQWlyTkdNMTFHRTJyWHFkUEZmTFJJNjFXdEZFbGtZSlJQ?= =?utf-8?B?Nlk5bnNCQ3BVeVNaVHdUaG9MbXZtQnE4elROWUNzQWgyMmFmZ0dndjA4eVFx?= =?utf-8?B?Z2dNbFc3eFRJU2Z5QWZRRnZrbDZXY2QxQ3RLQkFadndScEY2aDMrREJxNFFy?= =?utf-8?B?KzJTZ2xmU3E5ajJ1U2Rpb2lLeXFEN1VuQnFvVnJMU21lN2ZtdTVlRG1tanlr?= =?utf-8?B?K3E3djRCNHl1T0xQdnF5RWYrZlBFbnFHNFpEWThPNmwrVml0MExockhUTzFE?= =?utf-8?B?SCt5NVUxMHZpZGhvY3JiL2RTUFE0ZVFHMmNlMTdjeFpkbDVEUWt2NG5ISVdR?= =?utf-8?B?anRPL1R1TnBjcDV1cTBtaE5tYUpMOEM5aWJnejMvZSt0QkVQdFFRR3p4emZV?= =?utf-8?B?ZldFdlJ2U0c4dzd6KzdaWTJWRm9iQ0M0bVlJVDVuNUFseUFlbjJMTGlsRjMx?= =?utf-8?B?MFJMNW5hVllBUWJLMzMvVVlsY2lkRUJUenFYeitIV1FyeEgveUU1TDFLWlNy?= =?utf-8?B?ZjBBRkZlZm5VNHBnb0tITlduZDlIK2xPbEgzSlN3SThMODljc3hMMnNtd2V3?= =?utf-8?B?L0x3amF3NngrSTQwQ0FGV1NNUmxBMXU4RzRyd3ZwQ1lGL1VBSHFwY0lnTmZC?= =?utf-8?B?bU5aVEV5bzkycWpOM09JMkRVZ2dZbDRCbStWMkF1YzJHUGVuc0Fwa3JxRjgr?= =?utf-8?B?NFRnQ1dRRkJqRGlvWEp5K0NSRTBmT0p6d3g2enFmMjVVakQzeVN6ckIzK0hT?= =?utf-8?B?UEYzU2VWRDN2ajFpTE8yYjEwdER3K2lJTnNUVjZwMVU3cHoyYzhLVUFGMk1P?= =?utf-8?B?SytIcnFZc1hFSm9TUXFqMDNvQVJidXNwUHRvTU1WdnpVdDF5MFdjb2ZML0Rv?= =?utf-8?B?dHEvaHNaT2F5alN5VzhOOVpDZ2QxcEJZZmpDcEc1cFN5czBxRXNaUExQRzRH?= =?utf-8?B?Y0hmdnVWWmRMU3NvVHJmcFd3em9VRzdVSzlxSkFxY3pVRy9tT09FTGlBb3p6?= =?utf-8?B?dHRnM1pTbHlPMjdoK2RFV1k4b1VqQUxTWUp6dTNJYStlajQ4d3BGeEdTY0h6?= =?utf-8?B?eXMxdnRORGFiTE5FTWZMMkkzOHhpTmVFZklWVmM0K2d0cnR1VWExVmwzeENt?= =?utf-8?B?NFo4bGo5MTBBbk9IVnN1NVlETG0ybGxEVWxtQjNFbzgwc3llUGpsVXdybFZl?= =?utf-8?B?bGNRSm9hWE40ZlpjNmc0c1V3T09jaXVIVmVWN3ZZYmpxTWo0WTQ1ZnNkbFkv?= =?utf-8?B?MW5zWjlOeHFOdC9CWlkvSUZ4aGl2SmJ1RnNGSzZIZG5rczk4Ynl2aTFQS2kw?= =?utf-8?B?WlBJMHpIcVlEVzloVFBwZHVvKzd0Z1lYeU5nb3haekFybmxiNFFkelFkSGMw?= =?utf-8?B?eTk5NnZqMktNazJUL3ArRTAwdTJpYzZ6VW1MRU1OUUtReUtaQk8vMGxHbzd6?= =?utf-8?B?RVVkWi9QTDlMUTYrMDBwU1ZZdTB4VS8xTUxPY1Vpc3diYnFtbzkybENuRWVB?= =?utf-8?B?ekFRaFBCTGFxY1NLSXZNQjVhSTdmSytxKzFoVUNYR25JUnFVMW1iVFJ1aS9T?= =?utf-8?B?MU50ZUJnNTA5SDdTT0c3N0pnMm5sNncrTWVLRzhKVnVWcDViTlJYaHI0Z1Nu?= =?utf-8?Q?GiaZIVMQEjuC1CQ41U=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN6PR13MB2334DCB45EB76B47C19AFDEE856B9SN6PR13MB2334namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR13MB2334.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f592f03e-b4b0-4b34-ce58-08d8e89ebc0f X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2021 17:12:52.9305 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LhickHhNIEiEQfVQYBt+ZcveisKYyyj2/2y9m+MgJmK6A9rau0r5KgoJ1H4Zq1rSmgJOhT7ZmpN5gp3U4pPcOA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR13MB4287 Archived-At: Subject: Re: [Ecrit] Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 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, 16 Mar 2021 17:12:59 -0000 --_000_SN6PR13MB2334DCB45EB76B47C19AFDEE856B9SN6PR13MB2334namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXVycmF5LA0KDQpUaGVuIHdoeSBuZWVkIHRoaXMgZG9jdW1lbnQ/DQpJc27igJl0IGl0IGFscmVh ZHkgdGhlIHByYWN0aWNlIHRoYXQg4oCcVGhlIElFU0cgd2lsbCBiZSB0YXNrZWQgd2l0aCBhcHBv aW50aW5nIGEgZGVzaWduYXRlZCBleHBlcnQgKERFKSB0byByZXZpZXcgcmVnaXN0cmF0aW9uIHJl cXVlc3RzIGFnYWluc3QgdGhlIHB1Ymxpc2hlZCBzcGVjaWZpY2F0aW9u4oCdPw0KDQpMaW5kYQ0K DQpGcm9tOiBNdXJyYXkgUy4gS3VjaGVyYXd5IDxzdXBlcnVzZXJAZ21haWwuY29tPg0KU2VudDog VHVlc2RheSwgTWFyY2ggMTYsIDIwMjEgMTE6NDYgQU0NClRvOiBMaW5kYSBEdW5iYXIgPGxpbmRh LmR1bmJhckBmdXR1cmV3ZWkuY29tPg0KQ2M6IHNlY2RpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1l Y3JpdC1sb2NhdGlvbi1wcm9maWxlLXJlZ2lzdHJ5LXBvbGljeS5hbGxAaWV0Zi5vcmc7IGVjcml0 QGlldGYub3JnOyBsYXN0LWNhbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBTZWNkaXIgbGFzdCBj YWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWVjcml0LWxvY2F0aW9uLXByb2ZpbGUtcmVnaXN0cnkt cG9saWN5LTAxDQoNCkhpIExpbmRhLCB0aGFua3MgZm9yIHlvdXIgcmV2aWV3LiAgQ29tbWVudHMg YmVsb3cuDQoNCk9uIFR1ZSwgTWFyIDE2LCAyMDIxIGF0IDk6MzQgQU0gTGluZGEgRHVuYmFyIHZp YSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZzxtYWlsdG86bm9yZXBseUBpZXRmLm9yZz4+ IHdyb3RlOg0KVGhpcyBkb2N1bWVudCBkb2Vzbid0IHNlZW0gdG8gYmUgY29tcGxldGUuIFRoZSBk b2N1bWVudCBjbGFpbXMgdGhhdCBpdCBjaGFuZ2VzDQp0aGUgcG9saWN5IG9mIHRoZSBMb2NhdGlv bi10by1TZXJ2aWNlIFRyYW5zbGF0aW9uIChMb1NUKSBMb2NhdGlvbiBQcm9maWxlDQpyZWdpc3Ry eSBmcm9tIFN0YW5kYXJkcyBBY3Rpb24gdG8gU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCwgYnV0IGl0 IGRvZXNuJ3QNCnNwZWNpZnkgd2hhdCBpcyB0aGUgbmV3IHByb2NlZHVyZS4gIEl0IHNheXMgYWxs b3dpbmcgb3RoZXIgU0RPcyB0byBjaGFuZ2Ugb3INCmFkZCB2YWx1ZXMuIEJ1dCB3aGljaCBTRE9z IGFyZSBhbGxvd2VkPyBBcmUgdGhlcmUgYW55IHByb2NlZHVyZXMgdG8gaWRlbnRpZnkNCndoaWNo IFNET3MgYXJlIGxlZ2l0aW1hdGU/IGNhbiBhbnkgb3JnYW5pemF0aW9ucywgc2F5IFhZWiwgY2hh bmdlLCBhZGQgb3INCmRlbGV0ZSB0aGUgdmFsdWVzPw0KDQpTcGVjaWZpY2F0aW9uIFJlcXVpcmVk IGlzIGRlZmluZWQgaW4gUkZDIDgxNjIuICBUaGUgSUVTRyB3aWxsIGJlIHRhc2tlZCB3aXRoIGFw cG9pbnRpbmcgYSBkZXNpZ25hdGVkIGV4cGVydCAoREUpIHRvIHJldmlldyByZWdpc3RyYXRpb24g cmVxdWVzdHMgYWdhaW5zdCB0aGUgcHVibGlzaGVkIHNwZWNpZmljYXRpb24uICBUaGUgREUgd2ls bCBoYXZlIGRpc2NyZXRpb24gdG8gZGV0ZXJtaW5lIHdoZXRoZXIgYW4gYXBwbGljYXRpb24gc2hv dWxkIGJlIGFjY2VwdGVkLiAgVGhlIGRvY3VtZW50IGNvbnRhaW5zIG5vIGd1aWRhbmNlIGFib3V0 IHBhcnRpY3VsYXIgU0RPcywgc28gdGhlIERFIGlzIGxlZnQgdG8gZGVjaWRlIHdoZXRoZXIgdG8g ZmFjdG9yIHRoZSBzb3VyY2UgaW50byB0aGUgYXBwcm92YWwgb3IgcmVqZWN0aW9uIG9mIHRoZSBy ZXF1ZXN0Lg0KDQpTbyBhbnkgU0RPIGNhbiBtYWtlIGEgcmVxdWVzdCB0byB1cGRhdGUgdGhlIHJl Z2lzdHJ5LiAgVGhlIERFIG1ha2VzIHRoZSBjYWxsIGFib3V0ICJsZWdpdGltYXRlIi4NCg0KLU1T Sw0K --_000_SN6PR13MB2334DCB45EB76B47C19AFDEE856B9SN6PR13MB2334namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NdXJyYXksIDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGVuIHdoeSBuZWVkIHRoaXMgZG9jdW1lbnQ/IDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXNu4oCZdCBpdCBhbHJlYWR5IHRoZSBwcmFjdGljZSB0 aGF0IOKAnDxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5UaGUgSUVTRyB3aWxsIGJlIHRh c2tlZCB3aXRoIGFwcG9pbnRpbmcgYSBkZXNpZ25hdGVkIGV4cGVydCAoREUpIHRvIHJldmlldyBy ZWdpc3RyYXRpb24gcmVxdWVzdHMgYWdhaW5zdCB0aGUgcHVibGlzaGVkIHNwZWNpZmljYXRpb27i gJ0/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MaW5kYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gTXVycmF5IFMuIEt1Y2hlcmF3 eSAmbHQ7c3VwZXJ1c2VyQGdtYWlsLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks IE1hcmNoIDE2LCAyMDIxIDExOjQ2IEFNPGJyPg0KPGI+VG86PC9iPiBMaW5kYSBEdW5iYXIgJmx0 O2xpbmRhLmR1bmJhckBmdXR1cmV3ZWkuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gc2VjZGlyQGll dGYub3JnOyBkcmFmdC1pZXRmLWVjcml0LWxvY2F0aW9uLXByb2ZpbGUtcmVnaXN0cnktcG9saWN5 LmFsbEBpZXRmLm9yZzsgZWNyaXRAaWV0Zi5vcmc7IGxhc3QtY2FsbEBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1l Y3JpdC1sb2NhdGlvbi1wcm9maWxlLXJlZ2lzdHJ5LXBvbGljeS0wMTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgTGluZGEsIHRoYW5rcyBmb3IgeW91ciBy ZXZpZXcuJm5ic3A7IENvbW1lbnRzIGJlbG93LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBNYXIgMTYsIDIwMjEgYXQgOTozNCBBTSBMaW5kYSBE dW5iYXIgdmlhIERhdGF0cmFja2VyICZsdDs8YSBocmVmPSJtYWlsdG86bm9yZXBseUBpZXRmLm9y ZyI+bm9yZXBseUBpZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBkb2N1bWVudCBkb2Vzbid0 IHNlZW0gdG8gYmUgY29tcGxldGUuIFRoZSBkb2N1bWVudCBjbGFpbXMgdGhhdCBpdCBjaGFuZ2Vz PGJyPg0KdGhlIHBvbGljeSBvZiB0aGUgTG9jYXRpb24tdG8tU2VydmljZSBUcmFuc2xhdGlvbiAo TG9TVCkgTG9jYXRpb24gUHJvZmlsZTxicj4NCnJlZ2lzdHJ5IGZyb20gU3RhbmRhcmRzIEFjdGlv biB0byBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkLCBidXQgaXQgZG9lc24ndDxicj4NCnNwZWNpZnkg d2hhdCBpcyB0aGUgbmV3IHByb2NlZHVyZS4mbmJzcDsgSXQgc2F5cyBhbGxvd2luZyBvdGhlciBT RE9zIHRvIGNoYW5nZSBvcjxicj4NCmFkZCB2YWx1ZXMuIEJ1dCB3aGljaCBTRE9zIGFyZSBhbGxv d2VkPyBBcmUgdGhlcmUgYW55IHByb2NlZHVyZXMgdG8gaWRlbnRpZnk8YnI+DQp3aGljaCBTRE9z IGFyZSBsZWdpdGltYXRlPyBjYW4gYW55IG9yZ2FuaXphdGlvbnMsIHNheSBYWVosIGNoYW5nZSwg YWRkIG9yPGJyPg0KZGVsZXRlIHRoZSB2YWx1ZXM/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TcGVjaWZpY2F0aW9uIFJlcXVpcmVk IGlzIGRlZmluZWQgaW4gUkZDIDgxNjIuJm5ic3A7IFRoZSBJRVNHIHdpbGwgYmUgdGFza2VkIHdp dGggYXBwb2ludGluZyBhIGRlc2lnbmF0ZWQgZXhwZXJ0IChERSkgdG8gcmV2aWV3IHJlZ2lzdHJh dGlvbiByZXF1ZXN0cyBhZ2FpbnN0IHRoZSBwdWJsaXNoZWQgc3BlY2lmaWNhdGlvbi4mbmJzcDsg VGhlIERFIHdpbGwgaGF2ZSBkaXNjcmV0aW9uIHRvIGRldGVybWluZSB3aGV0aGVyIGFuIGFwcGxp Y2F0aW9uDQogc2hvdWxkIGJlIGFjY2VwdGVkLiZuYnNwOyBUaGUgZG9jdW1lbnQgY29udGFpbnMg bm8gZ3VpZGFuY2UgYWJvdXQgcGFydGljdWxhciBTRE9zLCBzbyB0aGUgREUgaXMgbGVmdCB0byBk ZWNpZGUgd2hldGhlciB0byBmYWN0b3IgdGhlIHNvdXJjZSBpbnRvIHRoZSBhcHByb3ZhbCBvciBy ZWplY3Rpb24gb2YgdGhlIHJlcXVlc3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGFueSBTRE8gY2FuIG1ha2UgYSByZXF1ZXN0IHRvIHVw ZGF0ZSB0aGUgcmVnaXN0cnkuJm5ic3A7IFRoZSBERSBtYWtlcyB0aGUgY2FsbCBhYm91dCAmcXVv dDtsZWdpdGltYXRlJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tTVNLPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN6PR13MB2334DCB45EB76B47C19AFDEE856B9SN6PR13MB2334namp_-- From nobody Tue Mar 16 10:39:35 2021 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 6DB073A1511; Tue, 16 Mar 2021 10:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 N8QHB6Z5tZuW; Tue, 16 Mar 2021 10:39:31 -0700 (PDT) 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 3F8A23A1512; Tue, 16 Mar 2021 10:39:31 -0700 (PDT) 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 12GHdMMt022522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Mar 2021 13:39:26 -0400 Date: Tue, 16 Mar 2021 10:39:21 -0700 From: Benjamin Kaduk To: Linda Dunbar Cc: "Murray S. Kucherawy" , "last-call@ietf.org" , "draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org" , "ecrit@ietf.org" , "secdir@ietf.org" Message-ID: <20210316173921.GG79563@kduck.mit.edu> References: <161591246412.5771.17798271339560020312@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [Ecrit] [Last-Call] Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 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, 16 Mar 2021 17:39:33 -0000 Hi Linda, The current registration procedure (visible at https://www.iana.org/assignments/lost-location-profiles/lost-location-profiles.xhtml) of Standards Action only requires a standards-track RFC to get an allocation; there is no designated expert involved in that procedure. RFC 8126 again remains a good reference for these registration policies. Thanks, Ben On Tue, Mar 16, 2021 at 05:12:52PM +0000, Linda Dunbar wrote: > Murray, > > Then why need this document? > Isn’t it already the practice that “The IESG will be tasked with appointing a designated expert (DE) to review registration requests against the published specification”? > > Linda > > From: Murray S. Kucherawy > Sent: Tuesday, March 16, 2021 11:46 AM > To: Linda Dunbar > Cc: secdir@ietf.org; draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org; ecrit@ietf.org; last-call@ietf.org > Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 > > Hi Linda, thanks for your review. Comments below. > > On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker > wrote: > This document doesn't seem to be complete. The document claims that it changes > the policy of the Location-to-Service Translation (LoST) Location Profile > registry from Standards Action to Specification Required, but it doesn't > specify what is the new procedure. It says allowing other SDOs to change or > add values. But which SDOs are allowed? Are there any procedures to identify > which SDOs are legitimate? can any organizations, say XYZ, change, add or > delete the values? > > Specification Required is defined in RFC 8162. The IESG will be tasked with appointing a designated expert (DE) to review registration requests against the published specification. The DE will have discretion to determine whether an application should be accepted. The document contains no guidance about particular SDOs, so the DE is left to decide whether to factor the source into the approval or rejection of the request. > > So any SDO can make a request to update the registry. The DE makes the call about "legitimate". > > -MSK > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Tue Mar 16 10:40:57 2021 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 C0D973A1511; Tue, 16 Mar 2021 10:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=gmail.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 I4SGDcWDyJNo; Tue, 16 Mar 2021 10:40:51 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 3DB963A14FE; Tue, 16 Mar 2021 10:40:51 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id m18so18701323vsa.1; Tue, 16 Mar 2021 10:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oZGnTSLJ0d/OVLtQLfrMwpRtm0fCQyymSkYFwGQmu6g=; b=Cwwz7ILW494pEJmYOHhRrv515J+MMxe09px/HGq1Au2hbtFH6SkVXoBZ6Hor53KHq+ KKgaMG14xAefLZj6NBgvMIux0d99/O+XfP3MRrvk3u2rzkN4ep7/vyzt3Hhb017xSxia pjB5CalXtz+HzCyZd6KTtSxl0LOIrB/RZYwXXaDBZtW4zaML17bTegEjnqh7jKakE3n2 G7uE42o76nvb2jTmUoODH+yd+gWa48TAe3CaJm/D3kQKXulqQ3KcDrGCVQMi2QbeUomp jBULU45DpnHtee+iiSAIMhIp8wkT/xYFkH+YjO0dyjBJ4elZJzIoEdWJgnCuECflAvJF YGTw== 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=oZGnTSLJ0d/OVLtQLfrMwpRtm0fCQyymSkYFwGQmu6g=; b=mjxt++ERCjJCTROm2Ov0wZSDsNBQNkfJMdAqnHpX+Rk3lZ8HN4vLgLZPcRno+zl7n2 XUoaRuYfAnLSZ1pvW/LsBtwpYhwgaZ8j+4zTx2O1f0yQkL3utHp9hZgwBE0mnPc4Eooc 0dAzNPZhrN/QzCByM/Sr8b9uepeu/c19h/BUBFKQ/LbwE7nP5EgDqnObimsmB0eKvSyu 0Fxqio0l3e2XmCUtvM89S0ZGUsiciSB52OV+9BcJ33u1sfo7WqCsg6i7gdXsH7duM9vN 8LA8mevgkESzoQI/1UZ0k7jyCChN/mNIjOkS2yD2U/WfbARghdrM54hItC8Og/IEstRj Y/zQ== X-Gm-Message-State: AOAM530s82C4erjmbiKJtOhnEWifsc/AQYIWKIuT+sKVOG2O7cXUq4YO CW3MaPoGu76VQk7TJ3n/PP/C5tRwSpcTG//i8YvflFyM X-Google-Smtp-Source: ABdhPJy9Cmw726xQjpfH5t2bYKexBWyVLMqTqx38oh7aIyT33bxK9WmcUc2+tJv6CW3G8BVB0JZdspksXEzcYU13aco= X-Received: by 2002:a67:c09b:: with SMTP id x27mr777275vsi.33.1615916449303; Tue, 16 Mar 2021 10:40:49 -0700 (PDT) MIME-Version: 1.0 References: <161591246412.5771.17798271339560020312@ietfa.amsl.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 16 Mar 2021 10:40:37 -0700 Message-ID: To: Linda Dunbar Cc: "secdir@ietf.org" , "draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org" , "ecrit@ietf.org" , "last-call@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f290c005bdaadd51" Archived-At: Subject: Re: [Ecrit] Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 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, 16 Mar 2021 17:40:53 -0000 --000000000000f290c005bdaadd51 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar wrote: > Then why need this document? > > Isn=E2=80=99t it already the practice that =E2=80=9C*The IESG will be tas= ked with > appointing a designated expert (DE) to review registration requests again= st > the published specification=E2=80=9D? * > No, the current rules for that registry are specified by Standards Action (Section 4.9 of RFC 8126), which requires a standards track RFC. There's no designated expert in that model. The working group wants to change the policy to the less restrictive model that allows for specifications published outside of the IETF to qualify, subject to expert review. -MSK --000000000000f290c005bdaadd51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Mar 16, 2021 at 10:12 AM Linda Du= nbar <linda.dunbar@futurew= ei.com> wrote:
Then why need this d= ocument?=20

Isn=E2=80=99t it already the practice that =E2=80=9C= The IESG will be tasked with appoin= ting a designated expert (DE) to review registration requests against the p= ublished specification=E2=80=9D?


No, the current rules for that= registry are specified by Standards Action (Section 4.9 of RFC 8126), whic= h requires a standards track RFC.=C2=A0 There's no designated expert in= that model.=C2=A0 The working group wants to change the policy to the less= restrictive model that allows for specifications published outside of the = IETF to qualify, subject to expert review.

-MSK
--000000000000f290c005bdaadd51-- From nobody Tue Mar 16 14:01:16 2021 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 BCCC43A0E7E; Tue, 16 Mar 2021 14:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 aKwEDIQvgHbl; Tue, 16 Mar 2021 14:01:09 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D841E3A0E04; Tue, 16 Mar 2021 14:01:09 -0700 (PDT) Received: from [169.254.151.95] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 16 Mar 2021 14:01:05 -0700 From: "Randall Gellens" To: "Murray S. Kucherawy" Cc: "Linda Dunbar" , secdir@ietf.org, draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org, ecrit@ietf.org, last-call@ietf.org Date: Tue, 16 Mar 2021 14:01:07 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: References: <161591246412.5771.17798271339560020312@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Ecrit] Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 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, 16 Mar 2021 21:01:11 -0000 I just want to add that the document currently does contain some guidance. Section 4 (IANA Considerations) contains: The reviewer should verify that: o the proposed new value is specified by the IETF, NENA, or a similar SDO in which location profiles are in scope; --Randall From nobody Fri Mar 19 04:01:19 2021 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 1A7253A0E23; Fri, 19 Mar 2021 04:01:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Zaheduzzaman Sarker via Datatracker To: "The IESG" Cc: draft-ietf-ecrit-location-profile-registry-policy@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, roger.marshall@comtechtel.com, roger.marshall@comtechtel.com X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Zaheduzzaman Sarker Message-ID: <161615167402.7459.4661817868534194858@ietfa.amsl.com> Date: Fri, 19 Mar 2021 04:01:14 -0700 Archived-At: Subject: [Ecrit] Zaheduzzaman Sarker's No Objection on draft-ietf-ecrit-location-profile-registry-policy-01: (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: Fri, 19 Mar 2021 11:01:14 -0000 Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-ecrit-location-profile-registry-policy-01: 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-location-profile-registry-policy/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- looks useful to me. From nobody Fri Mar 19 07:03:54 2021 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 5C6523A15EF; Fri, 19 Mar 2021 07:03:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suhas Nandakumar via Datatracker To: Cc: draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org, ecrit@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161616262926.769.15320475405477529524@ietfa.amsl.com> Reply-To: Suhas Nandakumar Date: Fri, 19 Mar 2021 07:03:49 -0700 Archived-At: Subject: [Ecrit] Genart last call review of draft-ietf-ecrit-location-profile-registry-policy-01 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: Fri, 19 Mar 2021 14:03:50 -0000 Reviewer: Suhas Nandakumar Review result: Ready 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 treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ecrit-location-profile-registry-policy-01 Reviewer: Suhas Nandakumar Review Date: 2021-03-19 IETF LC End Date: 2021-03-23 IESG Telechat date: 2021-03-25 Summary: Document looks fine to me. Its pretty clear in its purpose. Major issues: None Minor issues: None Nits/editorial comments: None From nobody Fri Mar 19 10:51:13 2021 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 1DB483A1B47; Fri, 19 Mar 2021 10:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.939 X-Spam-Level: X-Spam-Status: No, score=0.939 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_RELAY_MUA_TO_MX=2.839, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 e46b0ciX9FP8; Fri, 19 Mar 2021 10:51:10 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id DBB3D3A1B46; Fri, 19 Mar 2021 10:51:09 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 19 Mar 2021 10:51:05 -0700 From: "Randall Gellens" To: "Zaheduzzaman Sarker" Cc: "The IESG" , draft-ietf-ecrit-location-profile-registry-policy@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, roger.marshall@comtechtel.com Date: Fri, 19 Mar 2021 10:51:08 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <8BAB8F4A-8D76-40C6-9D47-9E0CB5060504@coretechnologyconsulting.com> In-Reply-To: <161615167402.7459.4661817868534194858@ietfa.amsl.com> References: <161615167402.7459.4661817868534194858@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ecrit] Zaheduzzaman Sarker's No Objection on draft-ietf-ecrit-location-profile-registry-policy-01: (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: Fri, 19 Mar 2021 17:51:11 -0000 Thank you for your review and positive comment, Zaheduzzaman. --Randall On 19 Mar 2021, at 4:01, Zaheduzzaman Sarker via Datatracker wrote: > Zaheduzzaman Sarker has entered the following ballot position for > draft-ietf-ecrit-location-profile-registry-policy-01: 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-location-profile-regi= stry-policy/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > looks useful to me. From nobody Fri Mar 19 10:52:19 2021 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 90FD53A1B4B; Fri, 19 Mar 2021 10:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.939 X-Spam-Level: X-Spam-Status: No, score=0.939 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_RELAY_MUA_TO_MX=2.839, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 h8HR3oiTocAz; Fri, 19 Mar 2021 10:52:10 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 793EC3A1B49; Fri, 19 Mar 2021 10:52:10 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 19 Mar 2021 10:52:06 -0700 From: "Randall Gellens" To: "Suhas Nandakumar" Cc: gen-art@ietf.org, draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org, ecrit@ietf.org, last-call@ietf.org Date: Fri, 19 Mar 2021 10:52:09 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <48E50BB6-9C54-473C-9779-4C5255D95F16@coretechnologyconsulting.com> In-Reply-To: <161616262926.769.15320475405477529524@ietfa.amsl.com> References: <161616262926.769.15320475405477529524@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; markup=markdown Archived-At: Subject: Re: [Ecrit] Genart last call review of draft-ietf-ecrit-location-profile-registry-policy-01 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: Fri, 19 Mar 2021 17:52:12 -0000 Thank you for your review and positive comments, Suhas. --Randall On 19 Mar 2021, at 7:03, Suhas Nandakumar via Datatracker wrote: > Reviewer: Suhas Nandakumar > Review result: Ready > > 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 treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-ecrit-location-profile-registry-policy-01 > Reviewer: Suhas Nandakumar > Review Date: 2021-03-19 > IETF LC End Date: 2021-03-23 > IESG Telechat date: 2021-03-25 > > Summary: > Document looks fine to me. Its pretty clear in its purpose. > > Major issues: > None > > Minor issues: > None > > Nits/editorial comments: > None From nobody Fri Mar 19 10:56:04 2021 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 AE1BD3A1B5D; Fri, 19 Mar 2021 10:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.94 X-Spam-Level: X-Spam-Status: No, score=0.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_RELAY_MUA_TO_MX=2.839, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 tRbpmRBLgiAY; Fri, 19 Mar 2021 10:55:53 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A28B53A1B84; Fri, 19 Mar 2021 10:55:52 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 19 Mar 2021 10:55:48 -0700 From: "Randall Gellens" To: "Linda Dunbar" Cc: secdir@ietf.org, draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org, ecrit@ietf.org, last-call@ietf.org, "Murray S. Kucherawy" , "Benjamin Kaduk" Date: Fri, 19 Mar 2021 10:55:51 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <161591246412.5771.17798271339560020312@ietfa.amsl.com> <161591246412.5771.17798271339560020312@ietfa.amsl.com> <161591246412.5771.17798271339560020312@ietfa.amsl.com> <20210316173921.GG79563@kduck.mit.edu> <20210316173921.GG79563@kduck.mit.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_B33E0B51-9FE4-43B4-8109-B19623A0CDF1_=" Embedded-HTML: [{"HTML":[4893, 1626], "plain":[3421, 1208], "uuid":"34A029A3-465F-4DE7-A39F-6E3D4D53F3D9"}, {"HTML":[6953, 1626], "plain":[4687, 1208], "uuid":"F520A1A3-1DD1-4C89-A527-DBD56B974BA4"}, {"HTML":[9375, 1626], "plain":[6087, 1208], "uuid":"DDD052BF-8A97-4A33-8A4C-CF2162D18B09"}, {"HTML":[11694, 3917], "plain":[7449, 1789], "uuid":"51A81255-64B8-4B40-8043-13A36AF2EB70"}, {"HTML":[16039, 3917], "plain":[9290, 1789], "uuid":"3C818FDA-ED69-46BD-BFE6-1355343515D0"}, {"HTML":[20746, 3917], "plain":[11265, 1789], "uuid":"1C477AC0-D120-4170-9E0E-E898A86C2559"}, {"HTML":[32802, 1244], "plain":[18183, 693], "uuid":"F4D745B0-346C-4720-BA91-5A36D62DE078"}, {"HTML":[34481, 1244], "plain":[18935, 693], "uuid":"36378602-B157-45A5-BD0E-1240F38088BA"}, {"HTML":[36522, 1244], "plain":[19821, 693], "uuid":"9FC73ACC-C119-4A51-AF54-2D2A47019374"}] Archived-At: Subject: Re: [Ecrit] Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 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: Fri, 19 Mar 2021 17:55:58 -0000 --=_MailMate_B33E0B51-9FE4-43B4-8109-B19623A0CDF1_= Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable Hi Linda, Thank you for reviewing the document. After the discussion, do you = still have any questions or do you feel there is any ambiguity that = needs to be resolved? --Randall On 16 Mar 2021, at 9:34, Linda Dunbar via Datatracker wrote: > Reviewer: Linda Dunbar > Review result: Not Ready > > I have reviewed this document as part of the security directorate's = > ongoing > effort to review all IETF documents being processed by the IESG. = > These > comments were written primarily for the benefit of the security area = > directors. > Document editors and WG chairs should treat these comments just like = > any other > last call comments. > > This document doesn't seem to be complete. The document claims that it = > changes > the policy of the Location-to-Service Translation (LoST) Location = > Profile > registry from Standards Action to Specification Required, but it = > doesn't > specify what is the new procedure. It says allowing other SDOs to = > change or > add values. But which SDOs are allowed? Are there any procedures to = > identify > which SDOs are legitimate? can any organizations, say XYZ, change, add = > or > delete the values? > > Best Regards, > Linda Dunbar On 16 Mar 2021, at 9:34, Linda Dunbar via Datatracker wrote: > Reviewer: Linda Dunbar > Review result: Not Ready > > I have reviewed this document as part of the security directorate's = > ongoing > effort to review all IETF documents being processed by the IESG. = > These > comments were written primarily for the benefit of the security area = > directors. > Document editors and WG chairs should treat these comments just like = > any other > last call comments. > > This document doesn't seem to be complete. The document claims that it = > changes > the policy of the Location-to-Service Translation (LoST) Location = > Profile > registry from Standards Action to Specification Required, but it = > doesn't > specify what is the new procedure. It says allowing other SDOs to = > change or > add values. But which SDOs are allowed? Are there any procedures to = > identify > which SDOs are legitimate? can any organizations, say XYZ, change, add = > or > delete the values? > > Best Regards, > Linda Dunbar > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 9:34, Linda Dunbar via Datatracker wrote: > Reviewer: Linda Dunbar > Review result: Not Ready > > I have reviewed this document as part of the security directorate's = > ongoing > effort to review all IETF documents being processed by the IESG. = > These > comments were written primarily for the benefit of the security area = > directors. > Document editors and WG chairs should treat these comments just like = > any other > last call comments. > > This document doesn't seem to be complete. The document claims that it = > changes > the policy of the Location-to-Service Translation (LoST) Location = > Profile > registry from Standards Action to Specification Required, but it = > doesn't > specify what is the new procedure. It says allowing other SDOs to = > change or > add values. But which SDOs are allowed? Are there any procedures to = > identify > which SDOs are legitimate? can any organizations, say XYZ, change, add = > or > delete the values? > > Best Regards, > Linda Dunbar > > > > -- = > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 9:45, Murray S. Kucherawy wrote: > Hi Linda, thanks for your review. Comments below. > > On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker < > noreply@ietf.org> wrote: > >> This document doesn't seem to be complete. The document claims that = >> it >> changes >> the policy of the Location-to-Service Translation (LoST) Location = >> Profile >> registry from Standards Action to Specification Required, but it = >> doesn't >> specify what is the new procedure. It says allowing other SDOs to = >> change >> or >> add values. But which SDOs are allowed? Are there any procedures to >> identify >> which SDOs are legitimate? can any organizations, say XYZ, change, = >> add or >> delete the values? >> > > Specification Required is defined in RFC 8162. The IESG will be = > tasked > with appointing a designated expert (DE) to review registration = > requests > against the published specification. The DE will have discretion to > determine whether an application should be accepted. The document = > contains > no guidance about particular SDOs, so the DE is left to decide whether = > to > factor the source into the approval or rejection of the request. > > So any SDO can make a request to update the registry. The DE makes = > the > call about "legitimate". > > -MSK On 16 Mar 2021, at 9:45, Murray S. Kucherawy wrote: > Hi Linda, thanks for your review. Comments below. > > On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker < > noreply@ietf.org> wrote: > >> This document doesn't seem to be complete. The document claims that = >> it >> changes >> the policy of the Location-to-Service Translation (LoST) Location = >> Profile >> registry from Standards Action to Specification Required, but it = >> doesn't >> specify what is the new procedure. It says allowing other SDOs to = >> change >> or >> add values. But which SDOs are allowed? Are there any procedures to >> identify >> which SDOs are legitimate? can any organizations, say XYZ, change, = >> add or >> delete the values? >> > > Specification Required is defined in RFC 8162. The IESG will be = > tasked > with appointing a designated expert (DE) to review registration = > requests > against the published specification. The DE will have discretion to > determine whether an application should be accepted. The document = > contains > no guidance about particular SDOs, so the DE is left to decide whether = > to > factor the source into the approval or rejection of the request. > > So any SDO can make a request to update the registry. The DE makes = > the > call about "legitimate". > > -MSK > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 9:45, Murray S. Kucherawy wrote: > Hi Linda, thanks for your review. Comments below. > > On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker < > noreply@ietf.org> wrote: > >> This document doesn't seem to be complete. The document claims that = >> it >> changes >> the policy of the Location-to-Service Translation (LoST) Location = >> Profile >> registry from Standards Action to Specification Required, but it = >> doesn't >> specify what is the new procedure. It says allowing other SDOs to = >> change >> or >> add values. But which SDOs are allowed? Are there any procedures to >> identify >> which SDOs are legitimate? can any organizations, say XYZ, change, = >> add or >> delete the values? >> > > Specification Required is defined in RFC 8162. The IESG will be = > tasked > with appointing a designated expert (DE) to review registration = > requests > against the published specification. The DE will have discretion to > determine whether an application should be accepted. The document = > contains > no guidance about particular SDOs, so the DE is left to decide whether = > to > factor the source into the approval or rejection of the request. > > So any SDO can make a request to update the registry. The DE makes = > the > call about "legitimate". > > -MSK > -- = > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 10:12, Linda Dunbar wrote: > Murray, > > Then why need this document? > Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be ta= sked with = > appointing a designated expert (DE) to review registration requests = > against the published specification=E2=80=9D? > > Linda > > From: Murray S. Kucherawy > Sent: Tuesday, March 16, 2021 11:46 AM > To: Linda Dunbar > Cc: secdir@ietf.org; = > draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org; = > ecrit@ietf.org; last-call@ietf.org > Subject: Re: Secdir last call review of = > draft-ietf-ecrit-location-profile-registry-policy-01 > > Hi Linda, thanks for your review. Comments below. > > On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker = > > wrote: > This document doesn't seem to be complete. The document claims that it = > changes > the policy of the Location-to-Service Translation (LoST) Location = > Profile > registry from Standards Action to Specification Required, but it = > doesn't > specify what is the new procedure. It says allowing other SDOs to = > change or > add values. But which SDOs are allowed? Are there any procedures to = > identify > which SDOs are legitimate? can any organizations, say XYZ, change, add = > or > delete the values? > > Specification Required is defined in RFC 8162. The IESG will be = > tasked with appointing a designated expert (DE) to review registration = > requests against the published specification. The DE will have = > discretion to determine whether an application should be accepted. = > The document contains no guidance about particular SDOs, so the DE is = > left to decide whether to factor the source into the approval or = > rejection of the request. > > So any SDO can make a request to update the registry. The DE makes = > the call about "legitimate". > > -MSK On 16 Mar 2021, at 10:12, Linda Dunbar wrote: > Murray, > > Then why need this document? > Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be ta= sked with = > appointing a designated expert (DE) to review registration requests = > against the published specification=E2=80=9D? > > Linda > > From: Murray S. Kucherawy > Sent: Tuesday, March 16, 2021 11:46 AM > To: Linda Dunbar > Cc: secdir@ietf.org; = > draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org; = > ecrit@ietf.org; last-call@ietf.org > Subject: Re: Secdir last call review of = > draft-ietf-ecrit-location-profile-registry-policy-01 > > Hi Linda, thanks for your review. Comments below. > > On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker = > > wrote: > This document doesn't seem to be complete. The document claims that it = > changes > the policy of the Location-to-Service Translation (LoST) Location = > Profile > registry from Standards Action to Specification Required, but it = > doesn't > specify what is the new procedure. It says allowing other SDOs to = > change or > add values. But which SDOs are allowed? Are there any procedures to = > identify > which SDOs are legitimate? can any organizations, say XYZ, change, add = > or > delete the values? > > Specification Required is defined in RFC 8162. The IESG will be = > tasked with appointing a designated expert (DE) to review registration = > requests against the published specification. The DE will have = > discretion to determine whether an application should be accepted. = > The document contains no guidance about particular SDOs, so the DE is = > left to decide whether to factor the source into the approval or = > rejection of the request. > > So any SDO can make a request to update the registry. The DE makes = > the call about "legitimate". > > -MSK > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 10:12, Linda Dunbar wrote: > Murray, > > Then why need this document? > Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be ta= sked with = > appointing a designated expert (DE) to review registration requests = > against the published specification=E2=80=9D? > > Linda > > From: Murray S. Kucherawy > Sent: Tuesday, March 16, 2021 11:46 AM > To: Linda Dunbar > Cc: secdir@ietf.org; = > draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org; = > ecrit@ietf.org; last-call@ietf.org > Subject: Re: Secdir last call review of = > draft-ietf-ecrit-location-profile-registry-policy-01 > > Hi Linda, thanks for your review. Comments below. > > On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker = > > wrote: > This document doesn't seem to be complete. The document claims that it = > changes > the policy of the Location-to-Service Translation (LoST) Location = > Profile > registry from Standards Action to Specification Required, but it = > doesn't > specify what is the new procedure. It says allowing other SDOs to = > change or > add values. But which SDOs are allowed? Are there any procedures to = > identify > which SDOs are legitimate? can any organizations, say XYZ, change, add = > or > delete the values? > > Specification Required is defined in RFC 8162. The IESG will be = > tasked with appointing a designated expert (DE) to review registration = > requests against the published specification. The DE will have = > discretion to determine whether an application should be accepted. = > The document contains no guidance about particular SDOs, so the DE is = > left to decide whether to factor the source into the approval or = > rejection of the request. > > So any SDO can make a request to update the registry. The DE makes = > the call about "legitimate". > > -MSK > -- = > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 10:39, Benjamin Kaduk wrote: > Hi Linda, > > The current registration procedure (visible at > https://www.iana.org/assignments/lost-location-profiles/lost-location-p= rofiles.xhtml) > of Standards Action only requires a standards-track RFC to get an > allocation; there is no designated expert involved in that procedure. > RFC 8126 again remains a good reference for these registration = > policies. > > Thanks, > > Ben > > > On Tue, Mar 16, 2021 at 05:12:52PM +0000, Linda Dunbar wrote: >> Murray, >> >> Then why need this document? >> Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be t= asked with = >> appointing a designated expert (DE) to review registration requests = >> against the published specification=E2=80=9D? >> >> Linda >> >> From: Murray S. Kucherawy >> Sent: Tuesday, March 16, 2021 11:46 AM >> To: Linda Dunbar >> Cc: secdir@ietf.org; = >> draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org; = >> ecrit@ietf.org; last-call@ietf.org >> Subject: Re: Secdir last call review of = >> draft-ietf-ecrit-location-profile-registry-policy-01 >> >> Hi Linda, thanks for your review. Comments below. >> >> On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker = >> > wrote: >> This document doesn't seem to be complete. The document claims that = >> it changes >> the policy of the Location-to-Service Translation (LoST) Location = >> Profile >> registry from Standards Action to Specification Required, but it = >> doesn't >> specify what is the new procedure. It says allowing other SDOs to = >> change or >> add values. But which SDOs are allowed? Are there any procedures to = >> identify >> which SDOs are legitimate? can any organizations, say XYZ, change, = >> add or >> delete the values? >> >> Specification Required is defined in RFC 8162. The IESG will be = >> tasked with appointing a designated expert (DE) to review = >> registration requests against the published specification. The DE = >> will have discretion to determine whether an application should be = >> accepted. The document contains no guidance about particular SDOs, = >> so the DE is left to decide whether to factor the source into the = >> approval or rejection of the request. >> >> So any SDO can make a request to update the registry. The DE makes = >> the call about "legitimate". >> >> -MSK > >> -- = >> last-call mailing list >> last-call@ietf.org >> https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 10:39, Benjamin Kaduk wrote: > Hi Linda, > > The current registration procedure (visible at > https://www.iana.org/assignments/lost-location-profiles/lost-location-p= rofiles.xhtml) > of Standards Action only requires a standards-track RFC to get an > allocation; there is no designated expert involved in that procedure. > RFC 8126 again remains a good reference for these registration = > policies. > > Thanks, > > Ben > > > On Tue, Mar 16, 2021 at 05:12:52PM +0000, Linda Dunbar wrote: >> Murray, >> >> Then why need this document? >> Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be t= asked with = >> appointing a designated expert (DE) to review registration requests = >> against the published specification=E2=80=9D? >> >> Linda >> >> From: Murray S. Kucherawy >> Sent: Tuesday, March 16, 2021 11:46 AM >> To: Linda Dunbar >> Cc: secdir@ietf.org; = >> draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org; = >> ecrit@ietf.org; last-call@ietf.org >> Subject: Re: Secdir last call review of = >> draft-ietf-ecrit-location-profile-registry-policy-01 >> >> Hi Linda, thanks for your review. Comments below. >> >> On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker = >> > wrote: >> This document doesn't seem to be complete. The document claims that = >> it changes >> the policy of the Location-to-Service Translation (LoST) Location = >> Profile >> registry from Standards Action to Specification Required, but it = >> doesn't >> specify what is the new procedure. It says allowing other SDOs to = >> change or >> add values. But which SDOs are allowed? Are there any procedures to = >> identify >> which SDOs are legitimate? can any organizations, say XYZ, change, = >> add or >> delete the values? >> >> Specification Required is defined in RFC 8162. The IESG will be = >> tasked with appointing a designated expert (DE) to review = >> registration requests against the published specification. The DE = >> will have discretion to determine whether an application should be = >> accepted. The document contains no guidance about particular SDOs, = >> so the DE is left to decide whether to factor the source into the = >> approval or rejection of the request. >> >> So any SDO can make a request to update the registry. The DE makes = >> the call about "legitimate". >> >> -MSK > >> -- = >> last-call mailing list >> last-call@ietf.org >> https://www.ietf.org/mailman/listinfo/last-call > > -- = > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 10:40, Murray S. Kucherawy wrote: > On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar = > > wrote: > >> Then why need this document? >> >> Isn=E2=80=99t it already the practice that =E2=80=9C*The IESG will be = tasked with >> appointing a designated expert (DE) to review registration requests = >> against >> the published specification=E2=80=9D? * >> > > No, the current rules for that registry are specified by Standards = > Action > (Section 4.9 of RFC 8126), which requires a standards track RFC. = > There's > no designated expert in that model. The working group wants to change = > the > policy to the less restrictive model that allows for specifications > published outside of the IETF to qualify, subject to expert review. > > -MSK On 16 Mar 2021, at 10:40, Murray S. Kucherawy wrote: > On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar = > > wrote: > >> Then why need this document? >> >> Isn=E2=80=99t it already the practice that =E2=80=9C*The IESG will be = tasked with >> appointing a designated expert (DE) to review registration requests = >> against >> the published specification=E2=80=9D? * >> > > No, the current rules for that registry are specified by Standards = > Action > (Section 4.9 of RFC 8126), which requires a standards track RFC. = > There's > no designated expert in that model. The working group wants to change = > the > policy to the less restrictive model that allows for specifications > published outside of the IETF to qualify, subject to expert review. > > -MSK > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 10:40, Murray S. Kucherawy wrote: > On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar = > > wrote: > >> Then why need this document? >> >> Isn=E2=80=99t it already the practice that =E2=80=9C*The IESG will be = tasked with >> appointing a designated expert (DE) to review registration requests = >> against >> the published specification=E2=80=9D? * >> > > No, the current rules for that registry are specified by Standards = > Action > (Section 4.9 of RFC 8126), which requires a standards track RFC. = > There's > no designated expert in that model. The working group wants to change = > the > policy to the less restrictive model that allows for specifications > published outside of the IETF to qualify, subject to expert review. > > -MSK > -- = > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 14:01, Randall Gellens wrote: > I just want to add that the document currently does contain some = > guidance. Section 4 (IANA Considerations) contains: > > The reviewer should verify that: > o the proposed new value is specified by the IETF, NENA, or a > similar SDO in which location profiles are in scope; > > --Randall On 16 Mar 2021, at 14:01, Randall Gellens wrote: > I just want to add that the document currently does contain some = > guidance. Section 4 (IANA Considerations) contains: > > The reviewer should verify that: > o the proposed new value is specified by the IETF, NENA, or a > similar SDO in which location profiles are in scope; > > --Randall On 16 Mar 2021, at 14:01, Randall Gellens wrote: > I just want to add that the document currently does contain some = > guidance. Section 4 (IANA Considerations) contains: > > The reviewer should verify that: > o the proposed new value is specified by the IETF, NENA, or a > similar SDO in which location profiles are in scope; > > --Randall On 16 Mar 2021, at 14:01, Randall Gellens wrote: > I just want to add that the document currently does contain some = > guidance. Section 4 (IANA Considerations) contains: > > The reviewer should verify that: > o the proposed new value is specified by the IETF, NENA, or a > similar SDO in which location profiles are in scope; > > --Randall > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 14:01, Randall Gellens wrote: > I just want to add that the document currently does contain some = > guidance. Section 4 (IANA Considerations) contains: > > The reviewer should verify that: > o the proposed new value is specified by the IETF, NENA, or a > similar SDO in which location profiles are in scope; > > --Randall > > -- = > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call --=_MailMate_B33E0B51-9FE4-43B4-8109-B19623A0CDF1_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Linda,

Thank you for reviewing the document. After the discussi= on, do you still have any questions or do you feel there is any ambiguity= that needs to be resolved?

--Randall

On 16 Mar 2021, at 9:34, Linda Dunbar via Datatracker wro= te:

Reviewer: Linda Dunbar
Review result: Not Ready

I have reviewed this document as part of the security dir= ectorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area dire= ctors.
Document editors and WG chairs should treat these comments just like any= other
last call comments.

This document doesn't seem to be complete. The document c= laims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn't<= br> specify what is the new procedure. It says allowing other SDOs to change= or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

Best Regards,
Linda Dunbar

On 16 Mar 2021, at 9:34, Linda Dunbar via Datatracker wro= te:

Reviewer: Linda Dunbar
Review result: Not Ready

I have reviewed this document as part of the security dir= ectorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area dire= ctors.
Document editors and WG chairs should treat these comments just like any= other
last call comments.

This document doesn't seem to be complete. The document c= laims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn't<= br> specify what is the new procedure. It says allowing other SDOs to change= or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

Best Regards,
Linda Dunbar

Ecrit mailing list
Ecrit@ietf.org=
https://www.ietf.org/mailman/listinfo/ecrit

On 16 Mar 2021, at 9:34, Linda Dunbar via Datatracker wro= te:

Reviewer: Linda Dunbar
Review result: Not Ready

I have reviewed this document as part of the security dir= ectorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area dire= ctors.
Document editors and WG chairs should treat these comments just like any= other
last call comments.

This document doesn't seem to be complete. The document c= laims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn't<= br> specify what is the new procedure. It says allowing other SDOs to change= or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

Best Regards,
Linda Dunbar

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

On 16 Mar 2021, at 9:45, Murray S. Kucherawy wrote:

Hi Linda, thanks for your review.=C2=A0 C= omments below.

On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Data= tracker <noreply@ietf.org> = wrote:
This = document doesn't seem to be complete. The document claims that it cha= nges
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn= 9;t
specify what is the new procedure.=C2=A0 It says allowing other SDOs to c= hange or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

Specification Requ= ired is defined in RFC 8162.=C2=A0 The IESG will be tasked with appointin= g a designated expert (DE) to review registration requests against the pu= blished specification.=C2=A0 The DE will have discretion to determine whe= ther an application should be accepted.=C2=A0 The document contains no gu= idance about particular SDOs, so the DE is left to decide whether to fact= or the source into the approval or rejection of the request.
So any SDO can make a request to update the registry.=C2=A0 = The DE makes the call about "legitimate".

<= div>-MSK

On 16 Mar 2021, at 9:45, Murray S. Kucherawy wrote:

Hi Linda, thanks for your review.=C2=A0 C= omments below.

On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Data= tracker <noreply@ietf.org> = wrote:
This = document doesn't seem to be complete. The document claims that it cha= nges
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn= 9;t
specify what is the new procedure.=C2=A0 It says allowing other SDOs to c= hange or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

Specification Requ= ired is defined in RFC 8162.=C2=A0 The IESG will be tasked with appointin= g a designated expert (DE) to review registration requests against the pu= blished specification.=C2=A0 The DE will have discretion to determine whe= ther an application should be accepted.=C2=A0 The document contains no gu= idance about particular SDOs, so the DE is left to decide whether to fact= or the source into the approval or rejection of the request.
So any SDO can make a request to update the registry.=C2=A0 = The DE makes the call about "legitimate".

<= div>-MSK

Ecrit mailing list
Ecrit@ietf.org=
https://www.ietf.org/mailman/listinfo/ecrit

On 16 Mar 2021, at 9:45, Murray S. Kucherawy wrote:

Hi Linda, thanks for your review.=C2=A0 C= omments below.

On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Data= tracker <noreply@ietf.org> = wrote:
This = document doesn't seem to be complete. The document claims that it cha= nges
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn= 9;t
specify what is the new procedure.=C2=A0 It says allowing other SDOs to c= hange or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

Specification Requ= ired is defined in RFC 8162.=C2=A0 The IESG will be tasked with appointin= g a designated expert (DE) to review registration requests against the pu= blished specification.=C2=A0 The DE will have discretion to determine whe= ther an application should be accepted.=C2=A0 The document contains no gu= idance about particular SDOs, so the DE is left to decide whether to fact= or the source into the approval or rejection of the request.
So any SDO can make a request to update the registry.=C2=A0 = The DE makes the call about "legitimate".

<= div>-MSK

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

On 16 Mar 2021, at 10:12, Linda Dunbar wrote:

= Murray,

= =C2=A0

= Then why need this document?

= Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be tasked with appointing a designated expert (= DE) to review registration requests against the published specification=E2= =80=9D?

= =C2=A0

= Linda

= =C2=A0

= From: Murray S. Kucherawy <superuser@gmail.com>
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: secdir@ietf.org; draft-ietf-ecrit-location-profile-registry-po= licy.all@ietf.org; ecrit@ietf.org; last-call@ietf.org
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-= profile-registry-policy-01

= =C2=A0

= Hi Linda, thanks for your review.=C2=A0 Comments below.

= =C2=A0

= On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker <noreply@ietf.org> wrote:

= This document doesn't seem to be complete. The document claims that it ch= anges
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn't<= br> specify what is the new procedure.=C2=A0 It says allowing other SDOs to c= hange or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

= =C2=A0

= Specification Required is defined in RFC 8162.=C2=A0 The IESG will be tas= ked with appointing a designated expert (DE) to review registration reque= sts against the published specification.=C2=A0 The DE will have discretio= n to determine whether an application should be accepted.=C2=A0 The document contains no guidance about partic= ular SDOs, so the DE is left to decide whether to factor the source into = the approval or rejection of the request.

= =C2=A0

= So any SDO can make a request to update the registry.=C2=A0 The DE makes = the call about "legitimate".

= =C2=A0

= -MSK

On 16 Mar 2021, at 10:12, Linda Dunbar wrote:

= Murray,

= =C2=A0

= Then why need this document?

= Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be tasked with appointing a designated expert (= DE) to review registration requests against the published specification=E2= =80=9D?

= =C2=A0

= Linda

= =C2=A0

= From: Murray S. Kucherawy <superuser@gmail.com>
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: secdir@ietf.org; draft-ietf-ecrit-location-profile-registry-po= licy.all@ietf.org; ecrit@ietf.org; last-call@ietf.org
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-= profile-registry-policy-01

= =C2=A0

= Hi Linda, thanks for your review.=C2=A0 Comments below.

= =C2=A0

= On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker <noreply@ietf.org> wrote:

= This document doesn't seem to be complete. The document claims that it ch= anges
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn't<= br> specify what is the new procedure.=C2=A0 It says allowing other SDOs to c= hange or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

= =C2=A0

= Specification Required is defined in RFC 8162.=C2=A0 The IESG will be tas= ked with appointing a designated expert (DE) to review registration reque= sts against the published specification.=C2=A0 The DE will have discretio= n to determine whether an application should be accepted.=C2=A0 The document contains no guidance about partic= ular SDOs, so the DE is left to decide whether to factor the source into = the approval or rejection of the request.

= =C2=A0

= So any SDO can make a request to update the registry.=C2=A0 The DE makes = the call about "legitimate".

= =C2=A0

= -MSK

Ecrit mailing list
Ecrit@ietf.org=
https://www.ietf.org/mailman/listinfo/ecrit

On 16 Mar 2021, at 10:12, Linda Dunbar wrote:

= Murray,

= =C2=A0

= Then why need this document?

= Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be tasked with appointing a designated expert (= DE) to review registration requests against the published specification=E2= =80=9D?

= =C2=A0

= Linda

= =C2=A0

= From: Murray S. Kucherawy <superuser@gmail.com>
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: secdir@ietf.org; draft-ietf-ecrit-location-profile-registry-po= licy.all@ietf.org; ecrit@ietf.org; last-call@ietf.org
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-= profile-registry-policy-01

= =C2=A0

= Hi Linda, thanks for your review.=C2=A0 Comments below.

= =C2=A0

= On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker <noreply@ietf.org> wrote:

= This document doesn't seem to be complete. The document claims that it ch= anges
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn't<= br> specify what is the new procedure.=C2=A0 It says allowing other SDOs to c= hange or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

= =C2=A0

= Specification Required is defined in RFC 8162.=C2=A0 The IESG will be tas= ked with appointing a designated expert (DE) to review registration reque= sts against the published specification.=C2=A0 The DE will have discretio= n to determine whether an application should be accepted.=C2=A0 The document contains no guidance about partic= ular SDOs, so the DE is left to decide whether to factor the source into = the approval or rejection of the request.

= =C2=A0

= So any SDO can make a request to update the registry.=C2=A0 The DE makes = the call about "legitimate".

= =C2=A0

= -MSK

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

On 16 Mar 2021, at 10:39, Benjamin Kaduk wrote:

Hi Linda,

The current registration procedure (visible at
https://www.iana.org/assignm= ents/lost-location-profiles/lost-location-profiles.xhtml)
of Standards Action only requires a standards-track RFC to get an
allocation; there is no designated expert involved in that procedure.
= RFC 8126 again remains a good reference for these registration policies.<= /p>

Thanks,

Ben

On Tue, Mar 16, 2021 at 05:12:52PM +0000, Linda Dunbar wr= ote:

Murray,

Then why need this document?
Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be task= ed with appointing a designated expert (DE) to review registration reques= ts against the published specification=E2=80=9D?

Linda

From: Murray S. Kucherawy superuser@gmail.com
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar linda.dunbar@futurewei.com
Cc: secdir@ietf.o= rg; draft-ietf-ecrit-location-profile-r= egistry-policy.all@ietf.org; ecrit@ietf.org; last-call@ietf.org
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile= -registry-policy-01

Hi Linda, thanks for your review. Comments below.

On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatrac= ker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:
This document doesn't seem to be complete. The document claims that it ch= anges
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn't<= br> specify what is the new procedure. It says allowing other SDOs to change= or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

Specification Required is defined in RFC 8162. The IESG = will be tasked with appointing a designated expert (DE) to review registr= ation requests against the published specification. The DE will have dis= cretion to determine whether an application should be accepted. The docu= ment contains no guidance about particular SDOs, so the DE is left to dec= ide whether to factor the source into the approval or rejection of the re= quest.

So any SDO can make a request to update the registry. Th= e DE makes the call about "legitimate".

-MSK

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

On 16 Mar 2021, at 10:39, Benjamin Kaduk wrote:

Hi Linda,

The current registration procedure (visible at
https://www.iana.org/assignm= ents/lost-location-profiles/lost-location-profiles.xhtml)
of Standards Action only requires a standards-track RFC to get an
allocation; there is no designated expert involved in that procedure.
= RFC 8126 again remains a good reference for these registration policies.<= /p>

Thanks,

Ben

On Tue, Mar 16, 2021 at 05:12:52PM +0000, Linda Dunbar wr= ote:

Murray,

Then why need this document?
Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be task= ed with appointing a designated expert (DE) to review registration reques= ts against the published specification=E2=80=9D?

Linda

From: Murray S. Kucherawy superuser@gmail.com
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar linda.dunbar@futurewei.com
Cc: secdir@ietf.o= rg; draft-ietf-ecrit-location-profile-r= egistry-policy.all@ietf.org; ecrit@ietf.org; last-call@ietf.org
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile= -registry-policy-01

Hi Linda, thanks for your review. Comments below.

On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatrac= ker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:
This document doesn't seem to be complete. The document claims that it ch= anges
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn't<= br> specify what is the new procedure. It says allowing other SDOs to change= or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

Specification Required is defined in RFC 8162. The IESG = will be tasked with appointing a designated expert (DE) to review registr= ation requests against the published specification. The DE will have dis= cretion to determine whether an application should be accepted. The docu= ment contains no guidance about particular SDOs, so the DE is left to dec= ide whether to factor the source into the approval or rejection of the re= quest.

So any SDO can make a request to update the registry. Th= e DE makes the call about "legitimate".

-MSK

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

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

On 16 Mar 2021, at 10:40, Murray S. Kucherawy wrote:

On Tue, Mar 16, 2021 at 10:12 AM Linda Du= nbar <linda.dunbar@futur= ewei.com> wrote:
Then why need this= document? =

Isn=E2=80=99t it already the practice that =E2=80=9C= The IESG will be tasked with appo= inting a designated expert (DE) to review registration requests against t= he published specification=E2=80=9D?


No, the current rules for th= at registry are specified by Standards Action (Section 4.9 of RFC 8126), = which requires a standards track RFC.=C2=A0 There's no designated exp= ert in that model.=C2=A0 The working group wants to change the policy to = the less restrictive model that allows for specifications published outsi= de of the IETF to qualify, subject to expert review.

=
-MSK

On 16 Mar 2021, at 10:40, Murray S. Kucherawy wrote:

On Tue, Mar 16, 2021 at 10:12 AM Linda Du= nbar <linda.dunbar@futur= ewei.com> wrote:
Then why need this= document? =

Isn=E2=80=99t it already the practice that =E2=80=9C= The IESG will be tasked with appo= inting a designated expert (DE) to review registration requests against t= he published specification=E2=80=9D?


No, the current rules for th= at registry are specified by Standards Action (Section 4.9 of RFC 8126), = which requires a standards track RFC.=C2=A0 There's no designated exp= ert in that model.=C2=A0 The working group wants to change the policy to = the less restrictive model that allows for specifications published outsi= de of the IETF to qualify, subject to expert review.

=
-MSK

Ecrit mailing list
Ecrit@ietf.org=
https://www.ietf.org/mailman/listinfo/ecrit

On 16 Mar 2021, at 10:40, Murray S. Kucherawy wrote:

On Tue, Mar 16, 2021 at 10:12 AM Linda Du= nbar <linda.dunbar@futur= ewei.com> wrote:
Then why need this= document? =

Isn=E2=80=99t it already the practice that =E2=80=9C= The IESG will be tasked with appo= inting a designated expert (DE) to review registration requests against t= he published specification=E2=80=9D?


No, the current rules for th= at registry are specified by Standards Action (Section 4.9 of RFC 8126), = which requires a standards track RFC.=C2=A0 There's no designated exp= ert in that model.=C2=A0 The working group wants to change the policy to = the less restrictive model that allows for specifications published outsi= de of the IETF to qualify, subject to expert review.

=
-MSK

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

On 16 Mar 2021, at 14:01, Randall Gellens wrote:

I just want to add that the document currently does conta= in some guidance. Section 4 (IANA Considerations) contains:

The reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

--Randall

On 16 Mar 2021, at 14:01, Randall Gellens wrote:

I just want to add that the document currently does conta= in some guidance. Section 4 (IANA Considerations) contains:

The reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

--Randall

On 16 Mar 2021, at 14:01, Randall Gellens wrote:

I just want to add that the document currently does conta= in some guidance. Section 4 (IANA Considerations) contains:

The reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

--Randall

On 16 Mar 2021, at 14:01, Randall Gellens wrote:

I just want to add that the document currently does conta= in some guidance. Section 4 (IANA Considerations) contains:

The reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

--Randall

Ecrit mailing list
Ecrit@ietf.org=
https://www.ietf.org/mailman/listinfo/ecrit

On 16 Mar 2021, at 14:01, Randall Gellens wrote:

I just want to add that the document currently does conta= in some guidance. Section 4 (IANA Considerations) contains:

The reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

--Randall

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

--=_MailMate_B33E0B51-9FE4-43B4-8109-B19623A0CDF1_=-- From nobody Fri Mar 19 11:09:23 2021 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 5E0203A00C4; Fri, 19 Mar 2021 11:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=futurewei.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 rFjSqlFodKZr; Fri, 19 Mar 2021 11:09:16 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2129.outbound.protection.outlook.com [40.107.243.129]) (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 ABB503A006A; Fri, 19 Mar 2021 11:09:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C8x1CvFY/BZEkvKIuqvDynsTvv0JAHiYapGMFlUDe0Y5y3MVsKKzR6OwzqFXWZqtBhFDD+RDOGEHezx3JhfT0m6XijJNfcW3BrdQZ8A3Wmu4HwOk6qU8bxo//ZyJlhej/MooFkYPCRF1D16okrSY+G+HH5Mp+bq7D0cZqhrYUFpHVUeg+A9K6gqJ4PbrY3MsO+LDSQqtp0hj+PcmB1j6r3KFdDUl9VhiVwJbAZ+iBZDjEioMldbp26stSnhcgKGrmGWVAr30pIshwBqNiPu+5OJzIqo9UuZJ9jZ4GwzFTVZFMoN4F7RhA01mdRT0ylK5ltiYHt7GWDPPtduzald+KQ== 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=Wo8IcDdCYe+AoH90+LPM1oI5DY8NDzTsGVSuzD5ywvE=; b=SIK0t8n8ptCc/SaeCHX+s91HYuFe8qdSzfA2l8WOsqN+X1yrJsB1Seu0FfJcGUqHw3qME8HuyRYuvK67B56t16xz8a7uSsYnlrE2OY30rlLMT1jixyKog6/ahhLuSPp8No1daD+ObB2Ct/11BkizsNJp7h4wR1DcYKZPxJCCdwuhKfZ8f5fQfoyh8Z8ZJZYsXQe8g98DkRPSX+307dhwl8JBqMH8O8V8Fty5zNkzVfShPitTwvckpLt+RLWIhtc8jqodufVG+Jqsk3jPLtFMGaooa7mZt6qNmo5p+S2wHZncsd94n4hZaCRtb5NS99qzUjWCdS2QH20uGBYY33R1fg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Wo8IcDdCYe+AoH90+LPM1oI5DY8NDzTsGVSuzD5ywvE=; b=lSuKW51xkgOx0EKwXGjFiAsQWiTh6xQIaOfZrP0GAwtP9mHSVzE8SEV3TXPHG+YFtk/mTMsfQUxOV7/6TkT5SM0XFsAwJ3VT83xb+BwLa10MZ2tpgEZVLmJKxEqDBx2GRhO3dWBG+GPknZF4Fgjs1JhQHYK4rMWtt4MLcIYfWBQ= Received: from SN6PR13MB2334.namprd13.prod.outlook.com (2603:10b6:805:55::16) by SA1PR13MB4958.namprd13.prod.outlook.com (2603:10b6:806:189::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.10; Fri, 19 Mar 2021 18:09:11 +0000 Received: from SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::3050:546b:c47:a42a]) by SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::3050:546b:c47:a42a%6]) with mapi id 15.20.3977.010; Fri, 19 Mar 2021 18:09:11 +0000 From: Linda Dunbar To: Randall Gellens CC: "secdir@ietf.org" , "draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org" , "ecrit@ietf.org" , "last-call@ietf.org" , "Murray S. Kucherawy" , Benjamin Kaduk Thread-Topic: Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 Thread-Index: AQHXHOkcUCvg6FHqy0WVdZZ/yPofN6qLm/Mg Date: Fri, 19 Mar 2021 18:09:11 +0000 Message-ID: References: <161591246412.5771.17798271339560020312@ietfa.amsl.com> <161591246412.5771.17798271339560020312@ietfa.amsl.com> <161591246412.5771.17798271339560020312@ietfa.amsl.com> <20210316173921.GG79563@kduck.mit.edu> <20210316173921.GG79563@kduck.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: randy.pensive.org; dkim=none (message not signed) header.d=none;randy.pensive.org; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [72.180.73.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 76fc377f-b874-4239-b965-08d8eb0218df x-ms-traffictypediagnostic: SA1PR13MB4958: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LmV3c7kn4ZhnEsoIGcVFw9WLGSL7qy2Bjeeh5gJqif4SF8tg4t5ye9NVMkZQE8EgRZU6P2qne5x8hEXDSE5MmKIqfBeRh2yi0a+Kcro00aK2pzysY+eIAnZiugsDqwuy8zQ+IGkYC1teGzPe2202Oqc8XR2fbNbUmoLwoGRxC72AalV+t84FFMxQICHWwy+FyK/FU5ZjL/80HoLfBgtIn/AAh01FB8bb3y7+0/AVNMB1PrxrpOuQ+ZjTSRMnQxW/9RXnlU9ana3SvOqjM7ND6hhi7EJPc5j1AhASkl6JaWEamlNyWXqEHPiWrTP0kYrPShHMvjs4b+91URVWO6blsj8I8J45waSXQlmchXHgHRigToOY9jX/OSWItVLFZNTaHBpKtJZ5Kl/s5pOsY+xpzQv/7NyBSWV5ADmGrASet40iMrAqgpbpDg5d+fmiD7G03OXipuC6h3I9+kXBtUv955lzNDcyLDORLwO3iqdyGfXCCGMmaax8d/yF+wxKyiw03P5gocs6IeBMHFhkNbz8ChVRWhH5n6Ul95UK2kcXCwm8k/JF/+wksYK3KTH3iMJEPsU1T/b6PCJcQfle1WTfrJVBjwerJconjIxWhpEG0oHK8Gx9Gp+e1kZGhR3rIzbT34oCeSKWkCmW64H3SDum+33TCIedrioZSnC7WoE05I+DsrJ/6fWf23eg93WK+o+w+NbfRMeI9ww/c8vNQHDYkJP5IPKLrfjOiF5N3Mvi38U= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR13MB2334.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(136003)(39840400004)(376002)(346002)(186003)(83380400001)(66446008)(66946007)(54906003)(71200400001)(316002)(30864003)(5660300002)(86362001)(52536014)(66476007)(76116006)(166002)(66556008)(64756008)(26005)(53546011)(38100700001)(8676002)(6506007)(478600001)(8936002)(9686003)(55016002)(966005)(44832011)(2906002)(7696005)(4326008)(33656002)(579004)(559001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?ei42XJvMAT6GmTE+Wsa3uiRYANAemshBqh7zu8/vAVMAT49K0I+2GjsmmMLJ?= =?us-ascii?Q?BQxVHDLv5gYm96A+tK1UTXS/vd39WJ/elzH8IVGCA5cPSItpUrrkO8oxK6RN?= =?us-ascii?Q?4abxQdduXaaQTq5CbbDgTVPielCQKh/ceoX1aMTgEVr/0aZd7CTrIqsSZmoB?= =?us-ascii?Q?T3EhOnYyE6ebX3frbHnuYa13U3SyX4lTXXLKL/IiKOGgRdD5MHj+VAZ7b9A/?= =?us-ascii?Q?h3Bm4tS+OkbZYjKqUeudKl+fEsqpvpmgRVafe61frs1krovShUb6iMmu1M/U?= =?us-ascii?Q?vpJE/dpMHs/EuwhHIGkzC3dLElAZnw9NqPkH6RqCWzBC6XeJpdlGTBOZjEzg?= =?us-ascii?Q?DlAFlGCpzCKZ7KCkzeNeOmL8uUIh5DzGiMazsRqQ7rk7y+Mw59/L9paOfr9o?= =?us-ascii?Q?j5KrRM4628ojQUWfbPY94l3CWre3OmCScXBiX67TxXuKgVzf5Ag9c0SZMiVY?= =?us-ascii?Q?O5VsA5kvuwgLF56bgWMCZKAisnge2ELimAruzZS9kAhvu33zR9R811j/Cfvd?= =?us-ascii?Q?d4CNHMcslk6xdI/8G2FK7eQbLqsD1F/Xdr+wIYBlkL+LIiCHrijMMTjcvRYU?= =?us-ascii?Q?6BxW8u6KnSeOBaEWdyfP0l+9A6715/owzxhnzQkl6e8U95LZ2Cav0Fg4qSQT?= =?us-ascii?Q?XRae7Jm8qAkdqZ08sqvVxNWTuFM5BcddYso1c+fMXZoa1D1BI2VG36Se4VlI?= =?us-ascii?Q?QIbdwY7aOJq1vev9wFnRDA8mg/cNbsy8Br69carc8n/ye1EM594fByK5694W?= =?us-ascii?Q?GzPIs5pxWp37hfNS2BDxCJvTByXBRNTnz6Dj9Q3TJ+S6VswmJ1wQaXZ318Nd?= =?us-ascii?Q?Ctf+QlQhrUfuZqX6SqEfOaMKiN/AysRL8ulb1otkIZZAwTxjasJe9bT1ekdB?= =?us-ascii?Q?yMQ9rUBCW4IXMNQwxvuks9+YQF6tlVyOBHesbD4HEbrZpSY3oZKa9a+CQosI?= =?us-ascii?Q?0MPa4ybmuaJOyPQo2f5MvcLuixi9wDCc69wpQGqPDxiQfwWzqDCZW3/eJfxF?= =?us-ascii?Q?6a/Cmf5ful9J1WFapvaN1dDDpIOOvJOfBXeehaAyXT6qtEaLadANTr7yyI5B?= =?us-ascii?Q?Gvqa0c4/b6TGI2oiur2srI0rheceYjVPGgG7jh73fCEq0Ej4LO47bYj8uuB3?= =?us-ascii?Q?zSjWFrca9vGELla2jYc1zcBz3KoBztBhl9/QLKSOT/2H6NPoGnTF3wWwuKAt?= =?us-ascii?Q?QnziRbMtjtsno5d/K0tbW9dpg4ghL86AjpN1VkfNEB+mdyD8k8zcbnjA3T0z?= =?us-ascii?Q?EQkkkVb5PBmkwkQVaiIHy2155VnIg/RLT9iSIxSYmc43qLuxWA+YrNF4iY7R?= =?us-ascii?Q?Kx0=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN6PR13MB23347EAFEEBBF83BA1827A4C85689SN6PR13MB2334namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR13MB2334.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 76fc377f-b874-4239-b965-08d8eb0218df X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2021 18:09:11.1672 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Oo9qeh+H1BA7mI10aIjPq2Y8qvEq/QpDU86aECnS9adg0AagRQn/RoVBgUsjr1+Sx4EHikB/ck09YWuEZTMAWA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR13MB4958 Archived-At: Subject: Re: [Ecrit] Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 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: Fri, 19 Mar 2021 18:09:21 -0000 --_000_SN6PR13MB23347EAFEEBBF83BA1827A4C85689SN6PR13MB2334namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Randall, No, I don't have any more comments. Replies are good. Linda From: Randall Gellens Sent: Friday, March 19, 2021 12:56 PM To: Linda Dunbar Cc: secdir@ietf.org; draft-ietf-ecrit-location-profile-registry-policy.all@= ietf.org; ecrit@ietf.org; last-call@ietf.org; Murray S. Kucherawy ; Benjamin Kaduk Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile-r= egistry-policy-01 Hi Linda, Thank you for reviewing the document. After the discussion, do you still ha= ve any questions or do you feel there is any ambiguity that needs to be res= olved? --Randall On 16 Mar 2021, at 9:34, Linda Dunbar via Datatracker wrote: Reviewer: Linda Dunbar Review result: Not Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments just like any ot= her last call comments. This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Best Regards, Linda Dunbar On 16 Mar 2021, at 9:34, Linda Dunbar via Datatracker wrote: Reviewer: Linda Dunbar Review result: Not Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments just like any ot= her last call comments. This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Best Regards, Linda Dunbar ________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 9:34, Linda Dunbar via Datatracker wrote: Reviewer: Linda Dunbar Review result: Not Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments just like any ot= her last call comments. This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Best Regards, Linda Dunbar -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 9:45, Murray S. Kucherawy wrote: Hi Linda, thanks for your review. Comments below. On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker > wrote: This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change o= r add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Specification Required is defined in RFC 8162. The IESG will be tasked wit= h appointing a designated expert (DE) to review registration requests again= st the published specification. The DE will have discretion to determine w= hether an application should be accepted. The document contains no guidanc= e about particular SDOs, so the DE is left to decide whether to factor the = source into the approval or rejection of the request. So any SDO can make a request to update the registry. The DE makes the cal= l about "legitimate". -MSK On 16 Mar 2021, at 9:45, Murray S. Kucherawy wrote: Hi Linda, thanks for your review. Comments below. On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker > wrote: This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change o= r add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Specification Required is defined in RFC 8162. The IESG will be tasked wit= h appointing a designated expert (DE) to review registration requests again= st the published specification. The DE will have discretion to determine w= hether an application should be accepted. The document contains no guidanc= e about particular SDOs, so the DE is left to decide whether to factor the = source into the approval or rejection of the request. So any SDO can make a request to update the registry. The DE makes the cal= l about "legitimate". -MSK ________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 9:45, Murray S. Kucherawy wrote: Hi Linda, thanks for your review. Comments below. On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker > wrote: This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change o= r add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Specification Required is defined in RFC 8162. The IESG will be tasked wit= h appointing a designated expert (DE) to review registration requests again= st the published specification. The DE will have discretion to determine w= hether an application should be accepted. The document contains no guidanc= e about particular SDOs, so the DE is left to decide whether to factor the = source into the approval or rejection of the request. So any SDO can make a request to update the registry. The DE makes the cal= l about "legitimate". -MSK -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 10:12, Linda Dunbar wrote: Murray, Then why need this document? Isn't it already the practice that "The IESG will be tasked with appointing= a designated expert (DE) to review registration requests against the publi= shed specification"? Linda From: Murray S. Kucherawy > Sent: Tuesday, March 16, 2021 11:46 AM To: Linda Dunbar > Cc: secdir@ietf.org; draft-ietf-ecrit-location-prof= ile-registry-policy.all@ietf.org; ecrit@ietf.org; last-c= all@ietf.org Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile-r= egistry-policy-01 Hi Linda, thanks for your review. Comments below. On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker > wrote: This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change o= r add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Specification Required is defined in RFC 8162. The IESG will be tasked wit= h appointing a designated expert (DE) to review registration requests again= st the published specification. The DE will have discretion to determine w= hether an application should be accepted. The document contains no guidanc= e about particular SDOs, so the DE is left to decide whether to factor the = source into the approval or rejection of the request. So any SDO can make a request to update the registry. The DE makes the cal= l about "legitimate". -MSK On 16 Mar 2021, at 10:12, Linda Dunbar wrote: Murray, Then why need this document? Isn't it already the practice that "The IESG will be tasked with appointing= a designated expert (DE) to review registration requests against the publi= shed specification"? Linda From: Murray S. Kucherawy > Sent: Tuesday, March 16, 2021 11:46 AM To: Linda Dunbar > Cc: secdir@ietf.org; draft-ietf-ecrit-location-prof= ile-registry-policy.all@ietf.org; ecrit@ietf.org; last-c= all@ietf.org Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile-r= egistry-policy-01 Hi Linda, thanks for your review. Comments below. On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker > wrote: This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change o= r add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Specification Required is defined in RFC 8162. The IESG will be tasked wit= h appointing a designated expert (DE) to review registration requests again= st the published specification. The DE will have discretion to determine w= hether an application should be accepted. The document contains no guidanc= e about particular SDOs, so the DE is left to decide whether to factor the = source into the approval or rejection of the request. So any SDO can make a request to update the registry. The DE makes the cal= l about "legitimate". -MSK ________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 10:12, Linda Dunbar wrote: Murray, Then why need this document? Isn't it already the practice that "The IESG will be tasked with appointing= a designated expert (DE) to review registration requests against the publi= shed specification"? Linda From: Murray S. Kucherawy > Sent: Tuesday, March 16, 2021 11:46 AM To: Linda Dunbar > Cc: secdir@ietf.org; draft-ietf-ecrit-location-prof= ile-registry-policy.all@ietf.org; ecrit@ietf.org; last-c= all@ietf.org Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile-r= egistry-policy-01 Hi Linda, thanks for your review. Comments below. On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker > wrote: This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change o= r add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Specification Required is defined in RFC 8162. The IESG will be tasked wit= h appointing a designated expert (DE) to review registration requests again= st the published specification. The DE will have discretion to determine w= hether an application should be accepted. The document contains no guidanc= e about particular SDOs, so the DE is left to decide whether to factor the = source into the approval or rejection of the request. So any SDO can make a request to update the registry. The DE makes the cal= l about "legitimate". -MSK -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 10:39, Benjamin Kaduk wrote: Hi Linda, The current registration procedure (visible at https://www.iana.org/assignments/lost-location-profiles/lost-location-profi= les.xhtml) of Standards Action only requires a standards-track RFC to get an allocation; there is no designated expert involved in that procedure. RFC 8126 again remains a good reference for these registration policies. Thanks, Ben On Tue, Mar 16, 2021 at 05:12:52PM +0000, Linda Dunbar wrote: Murray, Then why need this document? Isn't it already the practice that "The IESG will be tasked with appointing= a designated expert (DE) to review registration requests against the publi= shed specification"? Linda From: Murray S. Kucherawy superuser@gmail.com Sent: Tuesday, March 16, 2021 11:46 AM To: Linda Dunbar linda.dunbar@futurewei.com Cc: secdir@ietf.org; draft-ietf-ecrit-location-prof= ile-registry-policy.all@ietf.org; ecrit@ietf.org; last-c= all@ietf.org Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile-r= egistry-policy-01 Hi Linda, thanks for your review. Comments below. On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker >> wrote: This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Specification Required is defined in RFC 8162. The IESG will be tasked with= appointing a designated expert (DE) to review registration requests agains= t the published specification. The DE will have discretion to determine whe= ther an application should be accepted. The document contains no guidance a= bout particular SDOs, so the DE is left to decide whether to factor the sou= rce into the approval or rejection of the request. So any SDO can make a request to update the registry. The DE makes the call= about "legitimate". -MSK -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 10:39, Benjamin Kaduk wrote: Hi Linda, The current registration procedure (visible at https://www.iana.org/assignments/lost-location-profiles/lost-location-profi= les.xhtml) of Standards Action only requires a standards-track RFC to get an allocation; there is no designated expert involved in that procedure. RFC 8126 again remains a good reference for these registration policies. Thanks, Ben On Tue, Mar 16, 2021 at 05:12:52PM +0000, Linda Dunbar wrote: Murray, Then why need this document? Isn't it already the practice that "The IESG will be tasked with appointing= a designated expert (DE) to review registration requests against the publi= shed specification"? Linda From: Murray S. Kucherawy superuser@gmail.com Sent: Tuesday, March 16, 2021 11:46 AM To: Linda Dunbar linda.dunbar@futurewei.com Cc: secdir@ietf.org; draft-ietf-ecrit-location-prof= ile-registry-policy.all@ietf.org; ecrit@ietf.org; last-c= all@ietf.org Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile-r= egistry-policy-01 Hi Linda, thanks for your review. Comments below. On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker >> wrote: This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Specification Required is defined in RFC 8162. The IESG will be tasked with= appointing a designated expert (DE) to review registration requests agains= t the published specification. The DE will have discretion to determine whe= ther an application should be accepted. The document contains no guidance a= bout particular SDOs, so the DE is left to decide whether to factor the sou= rce into the approval or rejection of the request. So any SDO can make a request to update the registry. The DE makes the call= about "legitimate". -MSK -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 10:40, Murray S. Kucherawy wrote: On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar > wrote: Then why need this document? Isn't it already the practice that "The IESG will be tasked with appointing= a designated expert (DE) to review registration requests against the publi= shed specification"? No, the current rules for that registry are specified by Standards Action (= Section 4.9 of RFC 8126), which requires a standards track RFC. There's no= designated expert in that model. The working group wants to change the po= licy to the less restrictive model that allows for specifications published= outside of the IETF to qualify, subject to expert review. -MSK On 16 Mar 2021, at 10:40, Murray S. Kucherawy wrote: On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar > wrote: Then why need this document? Isn't it already the practice that "The IESG will be tasked with appointing= a designated expert (DE) to review registration requests against the publi= shed specification"? No, the current rules for that registry are specified by Standards Action (= Section 4.9 of RFC 8126), which requires a standards track RFC. There's no= designated expert in that model. The working group wants to change the po= licy to the less restrictive model that allows for specifications published= outside of the IETF to qualify, subject to expert review. -MSK ________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 10:40, Murray S. Kucherawy wrote: On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar > wrote: Then why need this document? Isn't it already the practice that "The IESG will be tasked with appointing= a designated expert (DE) to review registration requests against the publi= shed specification"? No, the current rules for that registry are specified by Standards Action (= Section 4.9 of RFC 8126), which requires a standards track RFC. There's no= designated expert in that model. The working group wants to change the po= licy to the less restrictive model that allows for specifications published= outside of the IETF to qualify, subject to expert review. -MSK -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 14:01, Randall Gellens wrote: I just want to add that the document currently does contain some guidance. = Section 4 (IANA Considerations) contains: The reviewer should verify that: o the proposed new value is specified by the IETF, NENA, or a similar SDO in which location profiles are in scope; --Randall On 16 Mar 2021, at 14:01, Randall Gellens wrote: I just want to add that the document currently does contain some guidance. = Section 4 (IANA Considerations) contains: The reviewer should verify that: o the proposed new value is specified by the IETF, NENA, or a similar SDO in which location profiles are in scope; --Randall On 16 Mar 2021, at 14:01, Randall Gellens wrote: I just want to add that the document currently does contain some guidance. = Section 4 (IANA Considerations) contains: The reviewer should verify that: o the proposed new value is specified by the IETF, NENA, or a similar SDO in which location profiles are in scope; --Randall On 16 Mar 2021, at 14:01, Randall Gellens wrote: I just want to add that the document currently does contain some guidance. = Section 4 (IANA Considerations) contains: The reviewer should verify that: o the proposed new value is specified by the IETF, NENA, or a similar SDO in which location profiles are in scope; --Randall ________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 14:01, Randall Gellens wrote: I just want to add that the document currently does contain some guidance. = Section 4 (IANA Considerations) contains: The reviewer should verify that: o the proposed new value is specified by the IETF, NENA, or a similar SDO in which location profiles are in scope; --Randall -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call --_000_SN6PR13MB23347EAFEEBBF83BA1827A4C85689SN6PR13MB2334namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Randall,

 

No, I don’t have any more comments. Replies ar= e good.

 

Linda

 

From: Randall Gellens <rg+ietf@randy.pensi= ve.org>
Sent: Friday, March 19, 2021 12:56 PM
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: secdir@ietf.org; draft-ietf-ecrit-location-profile-registry-poli= cy.all@ietf.org; ecrit@ietf.org; last-call@ietf.org; Murray S. Kucherawy &l= t;superuser@gmail.com>; Benjamin Kaduk <kaduk@mit.edu>
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-pr= ofile-registry-policy-01

 

Hi Linda,<= /o:p>

Thank you for r= eviewing the document. After the discussion, do you still have any question= s or do you feel there is any ambiguity that needs to be resolved?

--Randall<= /o:p>

On 16 Mar 2021,= at 9:34, Linda Dunbar via Datatracker wrote:

R= eviewer: Linda Dunbar
Review result: Not Ready

I= have reviewed this document as part of the security directorate's ongoing<= br> effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area direct= ors.
Document editors and WG chairs should treat these comments just like any ot= her
last call comments.

T= his document doesn't seem to be complete. The document claims that it chang= es
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or=
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

B= est Regards,
Linda Dunbar

On 16 Mar 2021,= at 9:34, Linda Dunbar via Datatracker wrote:

R= eviewer: Linda Dunbar
Review result: Not Ready

I= have reviewed this document as part of the security directorate's ongoing<= br> effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area direct= ors.
Document editors and WG chairs should treat these comments just like any ot= her
last call comments.

T= his document doesn't seem to be complete. The document claims that it chang= es
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or=
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

B= est Regards,
Linda Dunbar

E= crit mailing list
Ecrit@ietf.= org
https://www.ietf.org/mailman/listinfo/ecrit=

On 16 Mar 2021,= at 9:34, Linda Dunbar via Datatracker wrote:

R= eviewer: Linda Dunbar
Review result: Not Ready

I= have reviewed this document as part of the security directorate's ongoing<= br> effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area direct= ors.
Document editors and WG chairs should treat these comments just like any ot= her
last call comments.

T= his document doesn't seem to be complete. The document claims that it chang= es
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or=
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

B= est Regards,
Linda Dunbar

-= -
last-call mailing list
last-ca= ll@ietf.org
https://www.ietf.org/mailman/listinfo/last-c= all

On 16 Mar 2021,= at 9:45, Murray S. Kucherawy wrote:

Hi Linda, thanks for your review.  Comments below.<= o:p>

 

On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatra= cker <noreply@ietf.org> wrote= :

This document doesn't seem to be complete. The document = claims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure.  It says allowing other SDOs to cha= nge or
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

 

Specification Required is defined in RFC 8162.  The= IESG will be tasked with appointing a designated expert (DE) to review reg= istration requests against the published specification.  The DE will have discretion to determine whether an application should be = accepted.  The document contains no guidance about particular SDOs, so= the DE is left to decide whether to factor the source into the approval or= rejection of the request.

 

So any SDO can make a request to update the registry.&nb= sp; The DE makes the call about "legitimate".

 

-MSK

On 16 Mar 2021,= at 9:45, Murray S. Kucherawy wrote:

Hi Linda, thanks for your review.  Comments below.<= o:p>

 

On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatra= cker <noreply@ietf.org> wrote= :

This document doesn't seem to be complete. The document = claims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure.  It says allowing other SDOs to cha= nge or
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

 

Specification Required is defined in RFC 8162.  The= IESG will be tasked with appointing a designated expert (DE) to review reg= istration requests against the published specification.  The DE will have discretion to determine whether an application should be = accepted.  The document contains no guidance about particular SDOs, so= the DE is left to decide whether to factor the source into the approval or= rejection of the request.

 

So any SDO can make a request to update the registry.&nb= sp; The DE makes the call about "legitimate".

 

-MSK

E= crit mailing list
Ecrit@ietf.= org
https://www.ietf.org/mailman/listinfo/ecrit=

On 16 Mar 2021,= at 9:45, Murray S. Kucherawy wrote:

Hi Linda, thanks for your review.  Comments below.<= o:p>

 

On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatra= cker <noreply@ietf.org> wrote= :

This document doesn't seem to be complete. The document = claims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure.  It says allowing other SDOs to cha= nge or
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

 

Specification Required is defined in RFC 8162.  The= IESG will be tasked with appointing a designated expert (DE) to review reg= istration requests against the published specification.  The DE will have discretion to determine whether an application should be = accepted.  The document contains no guidance about particular SDOs, so= the DE is left to decide whether to factor the source into the approval or= rejection of the request.

 

So any SDO can make a request to update the registry.&nb= sp; The DE makes the call about "legitimate".

 

-MSK

-= -
last-call mailing list
last-ca= ll@ietf.org
https://www.ietf.org/mailman/listinfo/l= ast-call

On 16 Mar 2021,= at 10:12, Linda Dunbar wrote:

Murray,

 

Then why need this do= cument?

Isn’t it alread= y the practice that “The IESG= will be tasked with appointing a designated expert (DE) to review registra= tion requests against the published specification”?

 <= span style=3D"color:#777777">

Linda

 

From: Murray S. Kucherawy <superuser@gmail.com>
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar <l= inda.dunbar@futurewei.com>
Cc: secdir@ietf.org; draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org; ecrit@ietf.org; last-call@ietf.or= g
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-pr= ofile-registry-policy-01

 

Hi Linda, thanks for = your review.  Comments below.

 

On Tue, Mar 16, 2021 = at 9:34 AM Linda Dunbar via Datatracker <noreply@ietf.org> wrote:

This document doesn't= seem to be complete. The document claims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure.  It says allowing other SDOs to cha= nge or
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

 

Specification Require= d is defined in RFC 8162.  The IESG will be tasked with appointing a d= esignated expert (DE) to review registration requests against the published= specification.  The DE will have discretion to determine whether an application should be accepted.  The document= contains no guidance about particular SDOs, so the DE is left to decide wh= ether to factor the source into the approval or rejection of the request.

 

So any SDO can make a= request to update the registry.  The DE makes the call about "le= gitimate".

 

-MSK

On 16 Mar 2021,= at 10:12, Linda Dunbar wrote:

Murray,

 

Then why need this do= cument?

Isn’t it alread= y the practice that “The IESG= will be tasked with appointing a designated expert (DE) to review registra= tion requests against the published specification”?

 <= span style=3D"color:#777777">

Linda

 

From: Murray S. Kucherawy <superuser@gmail.com>
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar <l= inda.dunbar@futurewei.com>
Cc: secdir@ietf.org; draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org; ecrit@ietf.org; last-call@ietf.or= g
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-pr= ofile-registry-policy-01

 

Hi Linda, thanks for = your review.  Comments below.

 

On Tue, Mar 16, 2021 = at 9:34 AM Linda Dunbar via Datatracker <noreply@ietf.org> wrote:

This document doesn't= seem to be complete. The document claims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure.  It says allowing other SDOs to cha= nge or
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

 

Specification Require= d is defined in RFC 8162.  The IESG will be tasked with appointing a d= esignated expert (DE) to review registration requests against the published= specification.  The DE will have discretion to determine whether an application should be accepted.  The document= contains no guidance about particular SDOs, so the DE is left to decide wh= ether to factor the source into the approval or rejection of the request.

 

So any SDO can make a= request to update the registry.  The DE makes the call about "le= gitimate".

 

-MSK

E= crit mailing list
Ecrit@ietf.= org
<= span style=3D"color:#777777">https://www.ietf.org/mailman/listinfo/ecrit

On 16 Mar 2021,= at 10:12, Linda Dunbar wrote:

Murray,

 

Then why need this do= cument?

Isn’t it alread= y the practice that “The IESG= will be tasked with appointing a designated expert (DE) to review registra= tion requests against the published specification”?

 <= span style=3D"color:#777777">

Linda

 

From: Murray S. Kucherawy <superuser@gmail.com>
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar <l= inda.dunbar@futurewei.com>
Cc: secdir@ietf.org; draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org; ecrit@ietf.org; last-call@ietf.or= g
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-pr= ofile-registry-policy-01

 

Hi Linda, thanks for = your review.  Comments below.

 

On Tue, Mar 16, 2021 = at 9:34 AM Linda Dunbar via Datatracker <noreply@ietf.org> wrote:

This document doesn't= seem to be complete. The document claims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure.  It says allowing other SDOs to cha= nge or
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

 

Specification Require= d is defined in RFC 8162.  The IESG will be tasked with appointing a d= esignated expert (DE) to review registration requests against the published= specification.  The DE will have discretion to determine whether an application should be accepted.  The document= contains no guidance about particular SDOs, so the DE is left to decide wh= ether to factor the source into the approval or rejection of the request.

 

So any SDO can make a= request to update the registry.  The DE makes the call about "le= gitimate".

 

-MSK

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

On 16 Mar 2021,= at 10:39, Benjamin Kaduk wrote:

H= i Linda,

T= he current registration procedure (visible at
https= ://www.iana.org/assignments/lost-location-profiles/lost-location-profiles.x= html)
of Standards Action only requires a standards-track RFC to get an
allocation; there is no designated expert involved in that procedure.
RFC 8126 again remains a good reference for these registration policies.

T= hanks,

B= en

O= n Tue, Mar 16, 2021 at 05:12:52PM +0000, Linda Dunbar wrote:

M= urray,

T= hen why need this document?
Isn’t it already the practice that “The IESG will be tasked wit= h appointing a designated expert (DE) to review registration requests again= st the published specification”?

L= inda

F= rom: Murray S. Kucherawy superu= ser@gmail.com
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar linda.dunbar@futurewei.com
Cc: secdir= @ietf.org; draft-ietf-ecrit-location-profile-regi= stry-policy.all@ietf.org; ecrit@ietf.= org; last-ca= ll@ietf.org
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile-r= egistry-policy-01

H= i Linda, thanks for your review. Comments below.

O= n Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker <noreply@ietf.org<mail= to:noreply@ietf.org>> wrote:
This document doesn't seem to be complete. The document claims that it chan= ges
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or=
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

S= pecification Required is defined in RFC 8162. The IESG will be tasked with = appointing a designated expert (DE) to review registration requests against= the published specification. The DE will have discretion to determine whether an application should be accepted. The doc= ument contains no guidance about particular SDOs, so the DE is left to deci= de whether to factor the source into the approval or rejection of the reque= st.

S= o any SDO can make a request to update the registry. The DE makes the call = about "legitimate".

-= MSK

-= -
last-call mailing list
last-ca= ll@ietf.org
<= span style=3D"color:#999999">https://www.ietf.org/mailman/listinfo/last-cal= l

On 16 Mar 2021,= at 10:39, Benjamin Kaduk wrote:

H= i Linda,

T= he current registration procedure (visible at
https= ://www.iana.org/assignments/lost-location-profiles/lost-location-profiles.x= html)
of Standards Action only requires a standards-track RFC to get an
allocation; there is no designated expert involved in that procedure.
RFC 8126 again remains a good reference for these registration policies.

T= hanks,

B= en

O= n Tue, Mar 16, 2021 at 05:12:52PM +0000, Linda Dunbar wrote:

M= urray,

T= hen why need this document?
Isn’t it already the practice that “The IESG will be tasked wit= h appointing a designated expert (DE) to review registration requests again= st the published specification”?

L= inda

F= rom: Murray S. Kucherawy superu= ser@gmail.com
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar linda.dunbar@futurewei.com
Cc: secdir= @ietf.org; draft-ietf-ecrit-location-profile-regi= stry-policy.all@ietf.org; ecrit@ietf.= org; last-ca= ll@ietf.org
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile-r= egistry-policy-01

H= i Linda, thanks for your review. Comments below.

O= n Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker <noreply@ietf.org<mail= to:noreply@ietf.org>> wrote:
This document doesn't seem to be complete. The document claims that it chan= ges
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or=
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

S= pecification Required is defined in RFC 8162. The IESG will be tasked with = appointing a designated expert (DE) to review registration requests against= the published specification. The DE will have discretion to determine whether an application should be accepted. The doc= ument contains no guidance about particular SDOs, so the DE is left to deci= de whether to factor the source into the approval or rejection of the reque= st.

S= o any SDO can make a request to update the registry. The DE makes the call = about "legitimate".

-= MSK

-= -
last-call mailing list
last-ca= ll@ietf.org
https://www.ietf.org/mailman/listinfo/last-c= all

-= -
last-call mailing list
last-ca= ll@ietf.org
<= span style=3D"color:#777777">https://www.ietf.org/mailman/listinfo/last-cal= l

On 16 Mar 2021,= at 10:40, Murray S. Kucherawy wrote:

On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar <linda.dunbar@futurewei.com> = wrote:

Then why need this document?

Isn’t it already the practice that “The IESG will be tasked with appointing a designated expert (DE) to review registration = requests against the published specification”?

 

No, the current rules for that registry are specified by= Standards Action (Section 4.9 of RFC 8126), which requires a standards tra= ck RFC.  There's no designated expert in that model.  The working group wants to change the policy to the less rest= rictive model that allows for specifications published outside of the IETF = to qualify, subject to expert review.

 

-MSK

On 16 Mar 2021,= at 10:40, Murray S. Kucherawy wrote:

On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar <linda.dunbar@futurewei.com> = wrote:

Then why need this document?

Isn’t it already the practice that “The IESG will be tasked with appointing a designated expert (DE) to review registration = requests against the published specification”?

 

No, the current rules for that registry are specified by= Standards Action (Section 4.9 of RFC 8126), which requires a standards tra= ck RFC.  There's no designated expert in that model.  The working group wants to change the policy to the less rest= rictive model that allows for specifications published outside of the IETF = to qualify, subject to expert review.

 

-MSK

E= crit mailing list
Ecrit@ietf.= org
https://www.ietf.org/mailman/listinfo/ecrit

On 16 Mar 2021,= at 10:40, Murray S. Kucherawy wrote:

On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar <linda.dunbar@futurewei.com> = wrote:

Then why need this document?

Isn’t it already the practice that “The IESG will be tasked with appointing a designated expert (DE) to review registration = requests against the published specification”?

 

No, the current rules for that registry are specified by= Standards Action (Section 4.9 of RFC 8126), which requires a standards tra= ck RFC.  There's no designated expert in that model.  The working group wants to change the policy to the less rest= rictive model that allows for specifications published outside of the IETF = to qualify, subject to expert review.

 

-MSK

-= -
last-call mailing list
last-ca= ll@ietf.org
https://www.ietf.org/mailman/listinfo/l= ast-call

On 16 Mar 2021,= at 14:01, Randall Gellens wrote:

I= just want to add that the document currently does contain some guidance. S= ection 4 (IANA Considerations) contains:

T= he reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

-= -Randall

On 16 Mar 2021,= at 14:01, Randall Gellens wrote:

I= just want to add that the document currently does contain some guidance. S= ection 4 (IANA Considerations) contains:

T= he reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

-= -Randall

On 16 Mar 2021,= at 14:01, Randall Gellens wrote:

I= just want to add that the document currently does contain some guidance. S= ection 4 (IANA Considerations) contains:

T= he reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

-= -Randall

On 16 Mar 2021,= at 14:01, Randall Gellens wrote:

I= just want to add that the document currently does contain some guidance. S= ection 4 (IANA Considerations) contains:

T= he reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

-= -Randall

E= crit mailing list
Ecrit@ietf.= org
https://www.ietf.org/mailman/listinfo/ecrit=

On 16 Mar 2021,= at 14:01, Randall Gellens wrote:

I= just want to add that the document currently does contain some guidance. S= ection 4 (IANA Considerations) contains:

T= he reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

-= -Randall

-= -
last-call mailing list
last-ca= ll@ietf.org
https://www.ietf.org/mailman/listinfo/last-c= all

--_000_SN6PR13MB23347EAFEEBBF83BA1827A4C85689SN6PR13MB2334namp_-- From nobody Mon Mar 22 02:37:28 2021 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 2DE5B3A0D43; Mon, 22 Mar 2021 02:37:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-ecrit-location-profile-registry-policy@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, roger.marshall@comtechtel.com, roger.marshall@comtechtel.com X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <161640584660.26321.17518647007435500886@ietfa.amsl.com> Date: Mon, 22 Mar 2021 02:37:27 -0700 Archived-At: Subject: [Ecrit] Robert Wilton's No Objection on draft-ietf-ecrit-location-profile-registry-policy-01: (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: Mon, 22 Mar 2021 09:37:27 -0000 Robert Wilton has entered the following ballot position for draft-ietf-ecrit-location-profile-registry-policy-01: 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-location-profile-registry-policy/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thanks for this document. One minor comment: It might be helpful to readers to mention IANA in the abstract. E.g., changing "Translation (LoST) Location Profile registry" to "Translation (LoST) Location Profile IANA registry". Regards, Rob From nobody Mon Mar 22 13:06:14 2021 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 E43AE3A0D79; Mon, 22 Mar 2021 13:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.009 X-Spam-Level: X-Spam-Status: No, score=0.009 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01] 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 u9HZEMHWu_v5; Mon, 22 Mar 2021 13:06:11 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id DB4423A0D76; Mon, 22 Mar 2021 13:06:10 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 22 Mar 2021 13:06:06 -0700 From: "Randall Gellens" To: "Robert Wilton" Cc: "The IESG" , draft-ietf-ecrit-location-profile-registry-policy@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, roger.marshall@comtechtel.com Date: Mon, 22 Mar 2021 13:06:09 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <275AC479-2E0E-408B-9D8E-0C74159EA357@coretechnologyconsulting.com> In-Reply-To: <161640584660.26321.17518647007435500886@ietfa.amsl.com> References: <161640584660.26321.17518647007435500886@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Ecrit] Robert Wilton's No Objection on draft-ietf-ecrit-location-profile-registry-policy-01: (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, 22 Mar 2021 20:06:12 -0000 On 22 Mar 2021, at 2:37, Robert Wilton via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi, > > Thanks for this document. > > One minor comment: It might be helpful to readers to mention IANA in > the > abstract. > > E.g., changing "Translation (LoST) Location Profile registry" to > "Translation > (LoST) Location Profile IANA registry". > > Regards, > Rob Good idea, Rob, thanks. I've made the edit in pending version -02, which I will post after seeing any further comments. --Randall From nobody Tue Mar 23 13:07:24 2021 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 A82F53A1436; Tue, 23 Mar 2021 13:07:22 -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-location-profile-registry-policy@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, roger.marshall@comtechtel.com, roger.marshall@comtechtel.com X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <161653004205.32247.12293294218787273681@ietfa.amsl.com> Date: Tue, 23 Mar 2021 13:07:22 -0700 Archived-At: Subject: [Ecrit] Benjamin Kaduk's No Objection on draft-ietf-ecrit-location-profile-registry-policy-01: (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, 23 Mar 2021 20:07:23 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-ecrit-location-profile-registry-policy-01: 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-location-profile-registry-policy/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 4 IANA is requested to change the policy of the Location-to-Service Translation (LoST) Location Profile Registry (established by [RFC5222]) to Specification Required. The expert reviewer is designated by the responsible area director. The reviewer should verify that: (nit) per RFC 8126, the DE is "appointed by the IESG, normally upon recommendation by the relevant Area Director", which is not quite aligned with the "designated by the responsible area director" text used here. From nobody Tue Mar 23 13:31:47 2021 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 949FE3A150F; Tue, 23 Mar 2021 13:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoSm2gVfJUoT; Tue, 23 Mar 2021 13:31:40 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 548A63A150D; Tue, 23 Mar 2021 13:31:40 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 23 Mar 2021 13:31:35 -0700 From: "Randall Gellens" To: "Benjamin Kaduk" Cc: "The IESG" , draft-ietf-ecrit-location-profile-registry-policy@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, roger.marshall@comtechtel.com Date: Tue, 23 Mar 2021 13:31:38 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <74A50DF7-A345-48B0-8E4B-9336352CD828@coretechnologyconsulting.com> In-Reply-To: <161653004205.32247.12293294218787273681@ietfa.amsl.com> References: <161653004205.32247.12293294218787273681@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ecrit] Benjamin Kaduk's No Objection on draft-ietf-ecrit-location-profile-registry-policy-01: (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, 23 Mar 2021 20:31:42 -0000 On 23 Mar 2021, at 13:07, Benjamin Kaduk via Datatracker wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-ecrit-location-profile-registry-policy-01: 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-location-profile-regi= stry-policy/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 4 > > IANA is requested to change the policy of the Location-to-Service > Translation (LoST) Location Profile Registry (established by > [RFC5222]) to Specification Required. The expert reviewer is > designated by the responsible area director. The reviewer should > verify that: > > (nit) per RFC 8126, the DE is "appointed by the IESG, normally upon > recommendation by the relevant Area Director", which is not quite > aligned with the "designated by the responsible area director" text = > used > here. Hi Benjamin, Thank you for your review. I'm happy to change: The expert reviewer is designated by the responsible area director. to: The expert reviewer is designated per [RFC8126]. --Randall From nobody Wed Mar 24 11:54:22 2021 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 EE1BC3A3340; Wed, 24 Mar 2021 11:54:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: John Scudder via Datatracker To: "The IESG" Cc: draft-ietf-ecrit-location-profile-registry-policy@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, roger.marshall@comtechtel.com, roger.marshall@comtechtel.com X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: John Scudder Message-ID: <161661206045.16413.16077537204096407111@ietfa.amsl.com> Date: Wed, 24 Mar 2021 11:54:20 -0700 Archived-At: Subject: [Ecrit] John Scudder's No Objection on draft-ietf-ecrit-location-profile-registry-policy-01: (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: Wed, 24 Mar 2021 18:54:21 -0000 John Scudder has entered the following ballot position for draft-ietf-ecrit-location-profile-registry-policy-01: 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-location-profile-registry-policy/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Ben's nit; otherwise, looks good to me. From nobody Wed Mar 24 12:31:17 2021 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 5BEFA3A33F4; Wed, 24 Mar 2021 12:31:11 -0700 (PDT) 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=eggert.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 DycNjOWhv3ne; Wed, 24 Mar 2021 12:31:06 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 8693D3A33F3; Wed, 24 Mar 2021 12:31:06 -0700 (PDT) Received: from [IPv6:2a00:ac00:4000:400:9507:e9f6:f26d:fc6a] (unknown [IPv6:2a00:ac00:4000:400:9507:e9f6:f26d:fc6a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 1FADB60030E; Wed, 24 Mar 2021 21:30:46 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1616614246; bh=K9Cfw+ONmcvV47W6ZIUFEL54rh3iT6mNE4/Yk5m/oBM=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=QcF/VjKRln2joEgIMS1UpBNMKlVIRWSYZKWfotQQsQEAeO8RglOO2rkqTV0g0D7vb lInEnPyc09/P2YjZ2ICEtfXSfJN8fGgpE/kU0lTJwZU2p/KBSuG51jseCyQPbB1ifo y+x2VHWS6ZLXlClL6x3N3s3hLbcK+mQij3/TRSg8= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_98448F52-FFF0-45BE-8585-FEDF4174DAA0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 24 Mar 2021 21:30:45 +0200 In-Reply-To: <161616262926.769.15320475405477529524@ietfa.amsl.com> Cc: General Area Review Team , last-call@ietf.org, draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org, ecrit@ietf.org To: Suhas Nandakumar References: <161616262926.769.15320475405477529524@ietfa.amsl.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-MailScanner-ID: 1FADB60030E.A36B8 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Ecrit] [Gen-art] Genart last call review of draft-ietf-ecrit-location-profile-registry-policy-01 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: Wed, 24 Mar 2021 19:31:12 -0000 --Apple-Mail=_98448F52-FFF0-45BE-8585-FEDF4174DAA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Suhas, thanks for the review. I entered a No Objection ballot. Lars On 2021-3-19, at 16:03, Suhas Nandakumar via Datatracker = wrote: >=20 > Reviewer: Suhas Nandakumar > 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 treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-ecrit-location-profile-registry-policy-01 > Reviewer: Suhas Nandakumar > Review Date: 2021-03-19 > IETF LC End Date: 2021-03-23 > IESG Telechat date: 2021-03-25 >=20 > Summary: > Document looks fine to me. Its pretty clear in its purpose. >=20 > Major issues: > None >=20 > Minor issues: > None >=20 > Nits/editorial comments: > None >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_98448F52-FFF0-45BE-8585-FEDF4174DAA0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmBbk2UACgkQVLXDCb9w wVf2dA//YsxMz3wfhpEHz6gjbraDCf9aQrv3GxEqpNEZrjKnA7so3IMD1+0dHCHB XYtZTp/E8msRvQxmv1fYucHNPVF5Myv9hlG3/XjbHhA8fTXEZhGzQ5jAyKZb8iZt ePx1oj2PBfFGqNczOMDJXyyUTcwNzxuedbAq4FPMv/JlXhRYd3uL1RGtocW1bsRg e0zESRnAaR+g8an4kp7fMCwgiuRZgm/bZJCAdymwUJd4iI2LTvhS/tqr+/ydNHGV K8CiUH7NhhLIy300nu9N6P/4h99X/C+BktiOmpK+E4cj+bsCLuG1yjokjaAyYIQs zj941Jd1Z/DMTdhNRHdY+H/8Ip4AH7MnR9hj2aSo5ULUSLcKngrPNyLAGuY2B53Z nQr5g6jhp8FjnxhXGPvkSEDIwQALBVBrRGqw4UXtFCn0OWmnM5XQvYlxxYXQf3jk d7UHpc2G/HpP1mMJ4m/DTr7v9HgJ2gXoLhVfh0paXPETx8ufYIRe+mAfnli03XeH 0bgjiYtQySn/SLHtxSQd76xjVcLRlPWf5cgrgJGy18FqVl2YeKwcfGXxfrcFUO+5 dtdGdAavdafD9487FJl2CAMWk5frZM79h5/NaqSw2L9sQO3FNmAEwQr/VSE4HUdD 8WJxGeCi2i5b3BOlli/nr9ouveQP6MTYYx2Rv+woiojzunqsrbM= =uIAy -----END PGP SIGNATURE----- --Apple-Mail=_98448F52-FFF0-45BE-8585-FEDF4174DAA0-- From nobody Thu Mar 25 08:09:32 2021 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 0B34E3A24F3 for ; Thu, 25 Mar 2021 08:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 G2EwbU5-fpPJ for ; Thu, 25 Mar 2021 08:09:26 -0700 (PDT) Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) (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 5F5263A24EC for ; Thu, 25 Mar 2021 08:09:09 -0700 (PDT) Received: by mail-vk1-xa2e.google.com with SMTP id k76so465541vkk.10 for ; Thu, 25 Mar 2021 08:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=VZs6YK2yJXxDqJxaMGtdzlNP49KY4GGEQdhuPrKQ5CA=; b=X8oVmhDtEHhCYRJoMFLDRiYXb139ejBVdn5kJmf/2p2Hr3uXZLI2g0/lt3Fr0qqsiG jemX52qDmytvX3la9VTrTd2X+vYK1CjcwO+azg3sxrw2Akb81wczXg8aDRgf4Zbn1CQO i7N+Gr93AbSYUinR6/b+FXPIrZGF4svb7W5TkLRiDLjiQNwYPVbKOviXHVxHwQGb7veX izoZ4wCLMTkDZwzOxb1ZYF+G/04gDoS5BpCwL2sWAfN1U+CpINlYU+utIWu4AjepV5E4 7ONSXKzlESCgvaFvqd+TJgeyysWaCHrGLpJeW/roGasYyKr1CRWpeZaDBwhnxCdQRDGS 6rYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VZs6YK2yJXxDqJxaMGtdzlNP49KY4GGEQdhuPrKQ5CA=; b=I261Cdpu6dx1AqM5qLNceoY6rGRdJIYkssENCu6AQqY5xPDztdAmBwxL0Zpk4Jltb+ Rbpra3zbhfgFC2OtU4PcTCFZLgFq3A318BWSt0XeyecgZLHUvXm7FiCdOwfylMf/VZrp Fd2nsuj66eOKGO/eFLLwH3uRRujxuFBem0kt4xb5BP2nsA8QvpDUfq0aldvh0IyqQe/N XFoCkV3ULz8XihqvTfy1qO5pn5qsv+wl03nsvYM7y67oZ26CWfmUwx01GqvliPX2TkHa 4KjRH5bYYVvaHBlDKE5RA7cksL4Jb8gW0j+cm3wggrSDtPaN1Ih+LJL/m435E2JWt+G5 JptQ== X-Gm-Message-State: AOAM530YHRPWIsJA3Hm+VijeJ3gQ5S4omJtZ1a6qaDhUaDtTzPjF8S+C e04ktK5UCiQ2AO7HY78cPLnPSpOoP4KCcAKCGZSC4dcocmChoA== X-Google-Smtp-Source: ABdhPJwnclvhhk65Y6H2kcVwzbhe5O8JAm6qEHIwwhAu6jrrWUKZ2l/J+qGXMVaR5cZKSctELGAt9nmlJooElQNljDM= X-Received: by 2002:a1f:9ed8:: with SMTP id h207mr5273704vke.13.1616684947582; Thu, 25 Mar 2021 08:09:07 -0700 (PDT) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Thu, 25 Mar 2021 08:08:56 -0700 Message-ID: To: ecrit@ietf.org Content-Type: multipart/alternative; boundary="00000000000003f65f05be5dcc6f" Archived-At: Subject: [Ecrit] draft-ietf-ecrit-location-profile-registry-policy next steps 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, 25 Mar 2021 15:09:31 -0000 --00000000000003f65f05be5dcc6f Content-Type: text/plain; charset="UTF-8" Hi there, The IESG approved this document. A few ADs had comments I want to make sure were seen and considered before I send it to the RFC Editor. Please have a look at the ballot and let me know what you think. https://datatracker.ietf.org/doc/draft-ietf-ecrit-location-profile-registry-policy/ballot/ -MSK --00000000000003f65f05be5dcc6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,

The IESG approved = this document.=C2=A0 A few ADs had comments I want to make sure were seen a= nd considered before I send it to the RFC Editor.

= Please have a look at the ballot and let me know what you think.
=
-MSK
--00000000000003f65f05be5dcc6f-- From nobody Thu Mar 25 09:24:10 2021 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 7F14E3A26CA for ; Thu, 25 Mar 2021 09:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mLDxEldESZ3 for ; Thu, 25 Mar 2021 09:24:04 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 461E63A27F5 for ; Thu, 25 Mar 2021 09:23:23 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 25 Mar 2021 09:23:18 -0700 From: "Randall Gellens" To: "Murray S. Kucherawy" Cc: ecrit@ietf.org Date: Thu, 25 Mar 2021 09:23:21 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <2C8D2ECC-795E-4F4E-9FAA-2D3EC179559E@randy.pensive.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_4FAB1F98-6627-4994-895A-332B207A2021_=" Embedded-HTML: [{"HTML":[814, 603], "plain":[483, 327], "uuid":"9C001DF3-2E59-491C-8ACF-11EFC57A3FA9"}] Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-location-profile-registry-policy next steps 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, 25 Mar 2021 16:24:09 -0000 --=_MailMate_4FAB1F98-6627-4994-895A-332B207A2021_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Thanks, Murray. I'd already read and responded to the comments that = suggested a document edit and made the edits in version -02, which I was = waiting to submit until after seeing if there were more comments. I'll = upload it now. The only comment that expressed a concern and hasn't = resulted in a document edit is =C3=89ric's expression of annoyance at its= = US-centricness, which I replied to in email a few minutes ago. --Randall On 25 Mar 2021, at 8:08, Murray S. Kucherawy wrote: > Hi there, > > The IESG approved this document. A few ADs had comments I want to = > make > sure were seen and considered before I send it to the RFC Editor. > > Please have a look at the ballot and let me know what you think. > > https://datatracker.ietf.org/doc/draft-ietf-ecrit-location-profile-regi= stry-policy/ballot/ > > -MSK > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=_MailMate_4FAB1F98-6627-4994-895A-332B207A2021_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Thanks, Murray. I'd already read and responded to the com= ments that suggested a document edit and made the edits in version -02, w= hich I was waiting to submit until after seeing if there were more commen= ts. I'll upload it now. The only comment that expressed a concern and h= asn't resulted in a document edit is =C3=89ric's expression of annoyance = at its US-centricness, which I replied to in email a few minutes ago.

=

--Randall

On 25 Mar 2021, at 8:08, Murray S. Kucherawy wrote:

Hi there,

The IESG approved = this document.=C2=A0 A few ADs had comments I want to make sure were seen= and considered before I send it to the RFC Editor.

<= div>Please have a look at the ballot and let me know what you think.

______________________= _________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

--=_MailMate_4FAB1F98-6627-4994-895A-332B207A2021_=-- From nobody Thu Mar 25 09:25:27 2021 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 E3D043A26F2; Thu, 25 Mar 2021 09:25:19 -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: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ecrit@ietf.org Message-ID: <161668951981.21777.8111795633956296948@ietfa.amsl.com> Date: Thu, 25 Mar 2021 09:25:19 -0700 Archived-At: Subject: [Ecrit] I-D Action: draft-ietf-ecrit-location-profile-registry-policy-02.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: Thu, 25 Mar 2021 16:25:26 -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 : Changing the LoST Location Profile Registry Policy Author : Randall Gellens Filename : draft-ietf-ecrit-location-profile-registry-policy-02.txt Pages : 3 Date : 2021-03-25 Abstract: This document changes the policy of the Location-to-Service Translation (LoST) Location Profile IANA registry established by RFC5222 from Standards Action to Specification Required. This allows standards development organizations (SDOs) other than the IETF to add new values. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-location-profile-registry-policy/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ecrit-location-profile-registry-policy-02 https://datatracker.ietf.org/doc/html/draft-ietf-ecrit-location-profile-registry-policy-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-location-profile-registry-policy-02 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 Thu Mar 25 09:30:31 2021 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 D2A473A26EE; Thu, 25 Mar 2021 09:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jkbwn6NZjLXV; Thu, 25 Mar 2021 09:30:25 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 87E443A26ED; Thu, 25 Mar 2021 09:30:25 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 25 Mar 2021 09:30:21 -0700 From: "Randall Gellens" To: ecrit@ietf.org Cc: i-d-announce@ietf.org Date: Thu, 25 Mar 2021 09:30:24 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <161668951981.21777.8111795633956296948@ietfa.amsl.com> References: <161668951981.21777.8111795633956296948@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-location-profile-registry-policy-02.txt 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, 25 Mar 2021 16:30:30 -0000 Version -02 has two edits to address IESG comments: (1) Added "IANA" before "registry" in two places; (2) Replace "by the responsible area director" with "per [RFC8126]". --Randall On 25 Mar 2021, at 9:25, internet-drafts@ietf.org wrote: > 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 : Changing the LoST Location Profile Registry = > Policy > Author : Randall Gellens > Filename : = > draft-ietf-ecrit-location-profile-registry-policy-02.txt > Pages : 3 > Date : 2021-03-25 > > Abstract: > This document changes the policy of the Location-to-Service > Translation (LoST) Location Profile IANA registry established by > RFC5222 from Standards Action to Specification Required. This = > allows > standards development organizations (SDOs) other than the IETF to = > add > new values. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-location-profile-regi= stry-policy/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ecrit-location-profile-registry-= policy-02 > https://datatracker.ietf.org/doc/html/draft-ietf-ecrit-location-profile= -registry-policy-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-location-profile-r= egistry-policy-02 > > > 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/ > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Thu Mar 25 13:41:44 2021 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 685E43A2C76; Thu, 25 Mar 2021 13:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 bKNH_hjm7b6Y; Thu, 25 Mar 2021 13:41:41 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id F136E3A2C75; Thu, 25 Mar 2021 13:41:40 -0700 (PDT) Received: from [169.254.44.78] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 25 Mar 2021 13:41:35 -0700 From: "Randall Gellens" To: ecrit@ietf.org, "Robert Wilton" , "Benjamin Kaduk" , "Murray S. Kucherawy" , "John Scudder" Cc: "The IESG" , ecrit-chairs@ietf.org, roger.marshall@comtechtel.com, draft-ietf-ecrit-location-profile-registry-policy@ietf.org Date: Thu, 25 Mar 2021 13:41:39 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [Ecrit] Changes in -02 of draft-ietf-ecrit-location-profile-registry-policy 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, 25 Mar 2021 20:41:42 -0000 Version -02 (submitted earlier today) has two edits to address IESG comments: (1) Added "IANA" before "registry" in two places; (2) Replace "by the responsible area director" with "per [RFC8126]". --Randall From nobody Mon Mar 29 08:58:37 2021 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 0FEC83A194E for ; Mon, 29 Mar 2021 08:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPpPH8tgJVv7 for ; Mon, 29 Mar 2021 08:58:30 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id ECFC13A1949 for ; Mon, 29 Mar 2021 08:58:29 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 29 Mar 2021 08:58:24 -0700 From: "Randall Gellens" To: "RFC Errata System" Cc: br@brianrosen.net, Hannes.Tschofenig@gmx.net, superuser@gmail.com, francesca.palombini@ericsson.com, allison.mankin@gmail.com, roger.marshall@comtechtel.com, lars@eggert.org, ecrit@ietf.org Date: Mon, 29 Mar 2021 08:58:28 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <20210329083753.E28B4F407C4@rfc-editor.org> References: <20210329083753.E28B4F407C4@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Ecrit] [Editorial Errata Reported] RFC8148 (6500) 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, 29 Mar 2021 15:58:35 -0000 This does seem like an obvious typo that was missed before publication. I'm not sure if an errata is the best way of addressing it, rather than having IANA update the MIME Media Type Registration for application/EmergencyCall.VEDS+xml. --Randall On 29 Mar 2021, at 1:37, RFC Errata System wrote: > The following errata report has been submitted for RFC8148, > "Next-Generation Vehicle-Initiated Emergency Calls". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6500 > > -------------------------------------- > Type: Editorial > Reported by: Lars Eggert > > Section: 14.1 > > Original Text > ------------- > Change controller: The IESG > > > Corrected Text > -------------- > Change controller: The IESG > > > Notes > ----- > The current text has the email address of the "IETF discuss" list for > the IESG, which is incorrect. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8148 (draft-ietf-ecrit-car-crash-23) > -------------------------------------- > Title : Next-Generation Vehicle-Initiated Emergency > Calls > Publication Date : May 2017 > Author(s) : R. Gellens, B. Rosen, H. Tschofenig > Category : PROPOSED STANDARD > Source : Emergency Context Resolution with Internet > Technologies > Area : Applications and Real-Time > Stream : IETF > Verifying Party : IESG From nobody Mon Mar 29 09:36:10 2021 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 35ED63A1A5A for ; Mon, 29 Mar 2021 09:36:08 -0700 (PDT) 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=eggert.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 wjW11Cr7ijkx for ; Mon, 29 Mar 2021 09:36:03 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 BCC363A1A57 for ; Mon, 29 Mar 2021 09:36:03 -0700 (PDT) Received: from [IPv6:2a00:ac00:4000:400:114:2aa0:cd3d:b93f] (unknown [IPv6:2a00:ac00:4000:400:114:2aa0:cd3d:b93f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id BB6A860031A; Mon, 29 Mar 2021 19:35:07 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1617035707; bh=SQmMf19Ow8IviQFheqRbqr5qDqGpBD0VCCEDYOukJCw=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=tQ92tp8hc6QtIiCzQVVmsJje/LfPSxAOVYD1vcl1ynKGp83/O4RWPXJGKWGtPAy6L Zy5oFZ14lef/QU+PWEaxa4vhSKvgSwowmqQ6/qb/wr325FPKK+uCV8Yl+6CLMgwhOI GikLrP/ODRl5oej4s0Gfq1KAgtH+YitDdo2NYyJk= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Lars Eggert Mime-Version: 1.0 (1.0) Date: Mon, 29 Mar 2021 19:35:05 +0300 Message-Id: <309D6418-5163-471C-A4CE-203D1DACB627@eggert.org> References: Cc: RFC Errata System , br@brianrosen.net, Hannes.Tschofenig@gmx.net, superuser@gmail.com, francesca.palombini@ericsson.com, allison.mankin@gmail.com, roger.marshall@comtechtel.com, ecrit@ietf.org In-Reply-To: To: Randall Gellens X-MailScanner-ID: BB6A860031A.A380F X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Ecrit] [Editorial Errata Reported] RFC8148 (6500) 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, 29 Mar 2021 16:36:08 -0000 I didn=E2=80=99t see the change controller listed on the IANA page, which is= why I filed the errata. --=20 Sent from a mobile device; please excuse typos. > On Mar 29, 2021, at 18:58, Randall Gellens wrote: >=20 > =EF=BB=BFThis does seem like an obvious typo that was missed before public= ation. I'm not sure if an errata is the best way of addressing it, rather t= han having IANA update the MIME Media Type Registration for application/Emer= gencyCall.VEDS+xml. >=20 > --Randall >=20 >> On 29 Mar 2021, at 1:37, RFC Errata System wrote: >>=20 >> The following errata report has been submitted for RFC8148, >> "Next-Generation Vehicle-Initiated Emergency Calls". >>=20 >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid6500 >>=20 >> -------------------------------------- >> Type: Editorial >> Reported by: Lars Eggert >>=20 >> Section: 14.1 >>=20 >> Original Text >> ------------- >> Change controller: The IESG >>=20 >>=20 >> Corrected Text >> -------------- >> Change controller: The IESG >>=20 >>=20 >> Notes >> ----- >> The current text has the email address of the "IETF discuss" list for the= IESG, which is incorrect. >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC8148 (draft-ietf-ecrit-car-crash-23) >> -------------------------------------- >> Title : Next-Generation Vehicle-Initiated Emergency Calls >> Publication Date : May 2017 >> Author(s) : R. Gellens, B. Rosen, H. Tschofenig >> Category : PROPOSED STANDARD >> Source : Emergency Context Resolution with Internet Technolo= gies >> Area : Applications and Real-Time >> Stream : IETF >> Verifying Party : IESG From nobody Mon Mar 29 09:59:27 2021 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 5B74E3A1AE5 for ; Mon, 29 Mar 2021 09:59:26 -0700 (PDT) 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, RCVD_IN_DNSWL_BLOCKED=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 RhrABkiTWBPV for ; Mon, 29 Mar 2021 09:59:21 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBF13A1AEA for ; Mon, 29 Mar 2021 09:59:21 -0700 (PDT) Received: from [169.254.190.213] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 29 Mar 2021 09:59:15 -0700 From: "Randall Gellens" To: "Lars Eggert" Cc: "RFC Errata System" , br@brianrosen.net, Hannes.Tschofenig@gmx.net, superuser@gmail.com, francesca.palombini@ericsson.com, allison.mankin@gmail.com, roger.marshall@comtechtel.com, ecrit@ietf.org Date: Mon, 29 Mar 2021 09:59:11 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <309D6418-5163-471C-A4CE-203D1DACB627@eggert.org> References: <309D6418-5163-471C-A4CE-203D1DACB627@eggert.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ecrit] [Editorial Errata Reported] RFC8148 (6500) 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, 29 Mar 2021 16:59:26 -0000 My point is just that I do not know if an errata is sufficient to cause IANA to make the change. If it is, that's fine; if it isn't, what is the procedure? An email to IANA perhaps? --Randall On 29 Mar 2021, at 9:35, Lars Eggert wrote: > I didn’t see the change controller listed on the IANA page, which is > why I filed the errata. > > -- > Sent from a mobile device; please excuse typos. > >> On Mar 29, 2021, at 18:58, Randall Gellens >> wrote: >> >> This does seem like an obvious typo that was missed before >> publication. I'm not sure if an errata is the best way of addressing >> it, rather than having IANA update the MIME Media Type Registration >> for application/EmergencyCall.VEDS+xml. >> >> --Randall >> >>> On 29 Mar 2021, at 1:37, RFC Errata System wrote: >>> >>> The following errata report has been submitted for RFC8148, >>> "Next-Generation Vehicle-Initiated Emergency Calls". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> https://www.rfc-editor.org/errata/eid6500 >>> >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Lars Eggert >>> >>> Section: 14.1 >>> >>> Original Text >>> ------------- >>> Change controller: The IESG >>> >>> >>> Corrected Text >>> -------------- >>> Change controller: The IESG >>> >>> >>> Notes >>> ----- >>> The current text has the email address of the "IETF discuss" list >>> for the IESG, which is incorrect. >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC8148 (draft-ietf-ecrit-car-crash-23) >>> -------------------------------------- >>> Title : Next-Generation Vehicle-Initiated Emergency >>> Calls >>> Publication Date : May 2017 >>> Author(s) : R. Gellens, B. Rosen, H. Tschofenig >>> Category : PROPOSED STANDARD >>> Source : Emergency Context Resolution with Internet >>> Technologies >>> Area : Applications and Real-Time >>> Stream : IETF >>> Verifying Party : IESG From nobody Mon Mar 29 10:05:33 2021 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 1393B3A1B0F for ; Mon, 29 Mar 2021 10:05:31 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 2_2alsmTwgIz for ; Mon, 29 Mar 2021 10:05:26 -0700 (PDT) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 323DB3A1B17 for ; Mon, 29 Mar 2021 10:05:25 -0700 (PDT) Received: by mail-qv1-xf33.google.com with SMTP id q9so6795694qvm.6 for ; Mon, 29 Mar 2021 10:05:25 -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=ZTioDTSCuBYbZdySZQU+pWWbFvaRHyWvXFoN5Mab1ks=; b=J4gB0HTj6pDl3XePHTZkqZVLc7/ahvRim5OhKScHq2DV8R+IFmbZw/GhGFg1v+uxhC BkYxtuWVlp7Sn+xKqGarUPFXLUwV4xHYWrupQVzyExoslXOgQtyJQEA7gyLa+q4tZmed 6a8GO5z/7RkKBm5odt3qsAVrdraKlG2+xb1//Ks9zcefdOVV1UtMSH6vlCTUwXF2S5P3 S4uvrDg2OSiiQz/vWOCZytpf3F72m/4dV5L/fi7C36exNh4VV+TnElQ1npCJc+1rI4hX hTYCNMBCEC9xMlFg3pazOZ9gY6NZIvyebeudEA1VpSo8rmcymhImyM7/ziteoCG5Aq5L Nsaw== 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=ZTioDTSCuBYbZdySZQU+pWWbFvaRHyWvXFoN5Mab1ks=; b=jhIVWkr1f3rZHR1WNZVemQGEcTv7QVJZNF3i4jvfhmkQAd7Aj1ROE2wGiE31a1kLZ7 UdkQ3BiaQ1oZg2SK3BbuyvTWzkONGLaTGnNl+pl/o3RSW513y7spf29R7volubQlxO+p tQ0hnyFrGAsikn7M0YI9fL3KcN2dxkTHUBpHjQ0is/hODVLC52QJOzIl+OsRBV8bV+Hy KMMk1wlIAmAp3HlwQiA8krPxdKfK8nLCl5bJVAZMZKMbHRgM6q8xlh1uxewrIok0eEEK oo8G+4NSWz+7wCMG3JriQbUVCoTKKWyG4o9nayhummsPIEDzVOKOLAwUr6GpVgqG4p/U 4dnA== X-Gm-Message-State: AOAM5302CDOOTFIgqbC0awyea+3L3FgcaRh3REv1AmOg8f2UyZoT4uwz Jo8BtbDa5RzpE65zssuzl4iB2A== X-Google-Smtp-Source: ABdhPJx4Uu23dBMY5qAr1VVFZAwMBvEgZh2L0gtURmdb2hjF8quka4N7V39wn1NDO9Utmbh0LGpFMg== X-Received: by 2002:ad4:540a:: with SMTP id f10mr26042442qvt.26.1617037523242; Mon, 29 Mar 2021 10:05:23 -0700 (PDT) Received: from brians-mbp.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id k28sm13810136qki.101.2021.03.29.10.05.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Mar 2021 10:05:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Brian Rosen In-Reply-To: Date: Mon, 29 Mar 2021 13:05:21 -0400 Cc: Lars Eggert , RFC Errata System , Hannes.Tschofenig@gmx.net, "Murray S. Kucherawy" , Francesca Palombini , Allison Mankin , Roger Marshall , ecrit@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5C7F3288-ADC1-42E0-AC82-EE10F8734140@brianrosen.net> References: <309D6418-5163-471C-A4CE-203D1DACB627@eggert.org> To: Randall Gellens X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Ecrit] [Editorial Errata Reported] RFC8148 (6500) 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, 29 Mar 2021 17:05:31 -0000 I=E2=80=99ll ask. This is a simple problem. Brian > On Mar 29, 2021, at 12:59 PM, Randall Gellens = wrote: >=20 > My point is just that I do not know if an errata is sufficient to = cause IANA to make the change. If it is, that's fine; if it isn't, what = is the procedure? An email to IANA perhaps? >=20 > --Randall >=20 > On 29 Mar 2021, at 9:35, Lars Eggert wrote: >=20 >> I didn=E2=80=99t see the change controller listed on the IANA page, = which is why I filed the errata. >>=20 >> --=20 >> Sent from a mobile device; please excuse typos. >>=20 >>> On Mar 29, 2021, at 18:58, Randall Gellens = wrote: >>>=20 >>> =EF=BB=BFThis does seem like an obvious typo that was missed before = publication. I'm not sure if an errata is the best way of addressing = it, rather than having IANA update the MIME Media Type Registration for = application/EmergencyCall.VEDS+xml. >>>=20 >>> --Randall >>>=20 >>>> On 29 Mar 2021, at 1:37, RFC Errata System wrote: >>>>=20 >>>> The following errata report has been submitted for RFC8148, >>>> "Next-Generation Vehicle-Initiated Emergency Calls". >>>>=20 >>>> -------------------------------------- >>>> You may review the report below and at: >>>> https://www.rfc-editor.org/errata/eid6500 >>>>=20 >>>> -------------------------------------- >>>> Type: Editorial >>>> Reported by: Lars Eggert >>>>=20 >>>> Section: 14.1 >>>>=20 >>>> Original Text >>>> ------------- >>>> Change controller: The IESG >>>>=20 >>>>=20 >>>> Corrected Text >>>> -------------- >>>> Change controller: The IESG >>>>=20 >>>>=20 >>>> Notes >>>> ----- >>>> The current text has the email address of the "IETF discuss" list = for the IESG, which is incorrect. >>>>=20 >>>> Instructions: >>>> ------------- >>>> This erratum is currently posted as "Reported". If necessary, = please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party >>>> can log in to change the status and edit the report, if necessary. >>>>=20 >>>> -------------------------------------- >>>> RFC8148 (draft-ietf-ecrit-car-crash-23) >>>> -------------------------------------- >>>> Title : Next-Generation Vehicle-Initiated Emergency = Calls >>>> Publication Date : May 2017 >>>> Author(s) : R. Gellens, B. Rosen, H. Tschofenig >>>> Category : PROPOSED STANDARD >>>> Source : Emergency Context Resolution with Internet = Technologies >>>> Area : Applications and Real-Time >>>> Stream : IETF >>>> Verifying Party : IESG From nobody Mon Mar 29 13:55:22 2021 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 381383A215F for ; Mon, 29 Mar 2021 13:55:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 eJSe2nqDyz9N for ; Mon, 29 Mar 2021 13:55:14 -0700 (PDT) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 B72803A215D for ; Mon, 29 Mar 2021 13:55:14 -0700 (PDT) Received: by mail-qv1-xf2f.google.com with SMTP id t5so7152594qvs.5 for ; Mon, 29 Mar 2021 13:55:14 -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=NSmzAxsPnikPgQWAUmZgHGKE6dk7sO4ez1j0odd2sCM=; b=ihg1n+5cVt8y07a/ad+6H7v/9+T13KbXxSs5N6e6w5oSD+j8SvRvNbFagz5ZFd7cTq 8mCFdSm2ZMtHoT/Rw+ZrwKKy97OWDqc9gRtyOklXhZBpplEq8QhJxqY/NTu2cSdQ9Q0S iyrN4wkjSEitLTyHYnvXKjZgTLS4rXCogslQwzxKoYEvPAceWvpdVy7QHkxs4OEWRphg behEv+XVZxe+XswtHk3VqAoyMC0Ch9e5gR80hFIFYy7Wcops54BCpS3jwSC2SJFcZPBV qYWTSg+gAvUzJ0TPqYU5OBMv00vXQIQR98lsNQgeSOItn1lD74sl26TfWX8hnuX/DmLK MpJw== 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=NSmzAxsPnikPgQWAUmZgHGKE6dk7sO4ez1j0odd2sCM=; b=WESKnR+fbOAwtLs0bhALNfKaGNxR14nHmIkzW+cdtqwt4PuRke4u5H4A5JM9+730ib qKRgN4JR7AcXb5+2wMeE8afNfVgs0b4n39bHXhg058tiiYlHpsOgXQ8WGv5kc0dZEvaM GdGqjhI8QFtmx2BcOg/JCwb8sj5fpi1VrLirg8Cm0slD9waik7LB9PJgPMGSTjQhtPxc uCoRGP4d35KsBNWu6YLIjneufYsNKEXuE16ecOXH267R0IHvdEJ3xieZXDUzysN0mnx1 UZmV4Gtotvqa8Tkc//5pf8hrJZi6psmiKFRIbTlHhNZbpD2qgzcXlhdxm5KNIa6svYXM ajSA== X-Gm-Message-State: AOAM532Q6eGSL30ecj+bJVNrSWmw78FqZRYaa3CGjAK8lfcAp9QAihIH 2j9AUxICrr39O5kJ7AdQJaOk2g== X-Google-Smtp-Source: ABdhPJzIJjiZZNAqHS4UbwSuF24Qx3yhLVjCP+WduBf3HHTwyescOOLGeHPX+ejAK9NzGR6ZzBuV+Q== X-Received: by 2002:a05:6214:18d2:: with SMTP id cy18mr27217378qvb.50.1617051313093; Mon, 29 Mar 2021 13:55:13 -0700 (PDT) Received: from brians-mbp.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id u63sm11926755qtd.40.2021.03.29.13.55.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Mar 2021 13:55:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Brian Rosen In-Reply-To: <5C7F3288-ADC1-42E0-AC82-EE10F8734140@brianrosen.net> Date: Mon, 29 Mar 2021 16:55:10 -0400 Cc: Lars Eggert , RFC Errata System , Hannes.Tschofenig@gmx.net, "Murray S. Kucherawy" , Francesca Palombini , Allison Mankin , Roger Marshall , ecrit@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <362A1747-7C26-45CC-AF70-5C94B063D961@brianrosen.net> References: <309D6418-5163-471C-A4CE-203D1DACB627@eggert.org> <5C7F3288-ADC1-42E0-AC82-EE10F8734140@brianrosen.net> To: Randall Gellens X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Ecrit] [Editorial Errata Reported] RFC8148 (6500) 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, 29 Mar 2021 20:55:20 -0000 Approve the errata. IANA will fix it. I asked, they responded = promptly. Brian > On Mar 29, 2021, at 1:05 PM, Brian Rosen wrote: >=20 > I=E2=80=99ll ask. This is a simple problem. >=20 > Brian >=20 >=20 >> On Mar 29, 2021, at 12:59 PM, Randall Gellens = wrote: >>=20 >> My point is just that I do not know if an errata is sufficient to = cause IANA to make the change. If it is, that's fine; if it isn't, what = is the procedure? An email to IANA perhaps? >>=20 >> --Randall >>=20 >> On 29 Mar 2021, at 9:35, Lars Eggert wrote: >>=20 >>> I didn=E2=80=99t see the change controller listed on the IANA page, = which is why I filed the errata. >>>=20 >>> --=20 >>> Sent from a mobile device; please excuse typos. >>>=20 >>>> On Mar 29, 2021, at 18:58, Randall Gellens = wrote: >>>>=20 >>>> =EF=BB=BFThis does seem like an obvious typo that was missed before = publication. I'm not sure if an errata is the best way of addressing = it, rather than having IANA update the MIME Media Type Registration for = application/EmergencyCall.VEDS+xml. >>>>=20 >>>> --Randall >>>>=20 >>>>> On 29 Mar 2021, at 1:37, RFC Errata System wrote: >>>>>=20 >>>>> The following errata report has been submitted for RFC8148, >>>>> "Next-Generation Vehicle-Initiated Emergency Calls". >>>>>=20 >>>>> -------------------------------------- >>>>> You may review the report below and at: >>>>> https://www.rfc-editor.org/errata/eid6500 >>>>>=20 >>>>> -------------------------------------- >>>>> Type: Editorial >>>>> Reported by: Lars Eggert >>>>>=20 >>>>> Section: 14.1 >>>>>=20 >>>>> Original Text >>>>> ------------- >>>>> Change controller: The IESG >>>>>=20 >>>>>=20 >>>>> Corrected Text >>>>> -------------- >>>>> Change controller: The IESG >>>>>=20 >>>>>=20 >>>>> Notes >>>>> ----- >>>>> The current text has the email address of the "IETF discuss" list = for the IESG, which is incorrect. >>>>>=20 >>>>> Instructions: >>>>> ------------- >>>>> This erratum is currently posted as "Reported". If necessary, = please >>>>> use "Reply All" to discuss whether it should be verified or >>>>> rejected. When a decision is reached, the verifying party >>>>> can log in to change the status and edit the report, if necessary. >>>>>=20 >>>>> -------------------------------------- >>>>> RFC8148 (draft-ietf-ecrit-car-crash-23) >>>>> -------------------------------------- >>>>> Title : Next-Generation Vehicle-Initiated Emergency = Calls >>>>> Publication Date : May 2017 >>>>> Author(s) : R. Gellens, B. Rosen, H. Tschofenig >>>>> Category : PROPOSED STANDARD >>>>> Source : Emergency Context Resolution with Internet = Technologies >>>>> Area : Applications and Real-Time >>>>> Stream : IETF >>>>> Verifying Party : IESG >=20 From nobody Mon Mar 29 13:59:19 2021 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 531F43A216F for ; Mon, 29 Mar 2021 13:59:17 -0700 (PDT) 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, RCVD_IN_DNSWL_BLOCKED=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 7bAXxiYw3LAg for ; Mon, 29 Mar 2021 13:59:12 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5F04F3A216D for ; Mon, 29 Mar 2021 13:59:12 -0700 (PDT) Received: from [169.254.239.62] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 29 Mar 2021 13:59:06 -0700 From: "Randall Gellens" To: "Brian Rosen" Cc: "Lars Eggert" , "RFC Errata System" , Hannes.Tschofenig@gmx.net, "Murray S. Kucherawy" , "Francesca Palombini" , "Allison Mankin" , "Roger Marshall" , ecrit@ietf.org Date: Mon, 29 Mar 2021 13:59:10 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <1C90213B-B0C4-469B-8778-1DA0422F7384@coretechnologyconsulting.com> In-Reply-To: <362A1747-7C26-45CC-AF70-5C94B063D961@brianrosen.net> References: <309D6418-5163-471C-A4CE-203D1DACB627@eggert.org> <5C7F3288-ADC1-42E0-AC82-EE10F8734140@brianrosen.net> <362A1747-7C26-45CC-AF70-5C94B063D961@brianrosen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ecrit] [Editorial Errata Reported] RFC8148 (6500) 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, 29 Mar 2021 20:59:17 -0000 Great, thanks. --Randall On 29 Mar 2021, at 13:55, Brian Rosen wrote: > Approve the errata. IANA will fix it. I asked, they responded > promptly. > > Brian > > >> On Mar 29, 2021, at 1:05 PM, Brian Rosen wrote: >> >> I’ll ask. This is a simple problem. >> >> Brian >> >> >>> On Mar 29, 2021, at 12:59 PM, Randall Gellens >>> wrote: >>> >>> My point is just that I do not know if an errata is sufficient to >>> cause IANA to make the change. If it is, that's fine; if it isn't, >>> what is the procedure? An email to IANA perhaps? >>> >>> --Randall >>> >>> On 29 Mar 2021, at 9:35, Lars Eggert wrote: >>> >>>> I didn’t see the change controller listed on the IANA page, which >>>> is why I filed the errata. >>>> >>>> -- >>>> Sent from a mobile device; please excuse typos. >>>> >>>>> On Mar 29, 2021, at 18:58, Randall Gellens >>>>> wrote: >>>>> >>>>> This does seem like an obvious typo that was missed before >>>>> publication. I'm not sure if an errata is the best way of >>>>> addressing it, rather than having IANA update the MIME Media Type >>>>> Registration for application/EmergencyCall.VEDS+xml. >>>>> >>>>> --Randall >>>>> >>>>>> On 29 Mar 2021, at 1:37, RFC Errata System wrote: >>>>>> >>>>>> The following errata report has been submitted for RFC8148, >>>>>> "Next-Generation Vehicle-Initiated Emergency Calls". >>>>>> >>>>>> -------------------------------------- >>>>>> You may review the report below and at: >>>>>> https://www.rfc-editor.org/errata/eid6500 >>>>>> >>>>>> -------------------------------------- >>>>>> Type: Editorial >>>>>> Reported by: Lars Eggert >>>>>> >>>>>> Section: 14.1 >>>>>> >>>>>> Original Text >>>>>> ------------- >>>>>> Change controller: The IESG >>>>>> >>>>>> >>>>>> Corrected Text >>>>>> -------------- >>>>>> Change controller: The IESG >>>>>> >>>>>> >>>>>> Notes >>>>>> ----- >>>>>> The current text has the email address of the "IETF discuss" list >>>>>> for the IESG, which is incorrect. >>>>>> >>>>>> Instructions: >>>>>> ------------- >>>>>> This erratum is currently posted as "Reported". If necessary, >>>>>> please >>>>>> use "Reply All" to discuss whether it should be verified or >>>>>> rejected. When a decision is reached, the verifying party >>>>>> can log in to change the status and edit the report, if >>>>>> necessary. >>>>>> >>>>>> -------------------------------------- >>>>>> RFC8148 (draft-ietf-ecrit-car-crash-23) >>>>>> -------------------------------------- >>>>>> Title : Next-Generation Vehicle-Initiated Emergency >>>>>> Calls >>>>>> Publication Date : May 2017 >>>>>> Author(s) : R. Gellens, B. Rosen, H. Tschofenig >>>>>> Category : PROPOSED STANDARD >>>>>> Source : Emergency Context Resolution with Internet >>>>>> Technologies >>>>>> Area : Applications and Real-Time >>>>>> Stream : IETF >>>>>> Verifying Party : IESG >> From nobody Mon Mar 29 14:15:42 2021 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 67F1E3A21E7 for ; Mon, 29 Mar 2021 14:15:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 M2kj8-U6boS6 for ; Mon, 29 Mar 2021 14:15:35 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 7D87D3A21E6 for ; Mon, 29 Mar 2021 14:15:35 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id l13so10409571qtu.9 for ; Mon, 29 Mar 2021 14:15:35 -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=IwHyDqnT5r/a+G9yR88iIFTC1qAUI7XZqItCzejAmnA=; b=A5Y5LZSja1Kl796kpLZK/+rIKNp54nSXNPSdQE5/uWID8DuvjPgqF7ZCt2lG+gHVTU 5YIaXQgzB5+KIzdEyuwFt8gk2OHwUyQSWG50C8KTBvw5gJJv8MkzP4G/dZdUhqixaWli hovTVU9ZNnhFRLWqLljJNngH8eraIBwyG8VXmbbpmxV7VO9+7HhAREvaf6wco9P5S/Uy Mxxo8iRp4VhdF2X4cr/w2y8i23l9lCOPNu8SKCE3Ccn/lEdMuRXjbRLls+wcH28iiODU /NNcMBGho26L1CZ0575ytMOGHaT+b57fsTppBVkWegM0ix+K42EuqsqbKu5ai6GAxUpQ fcZQ== 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=IwHyDqnT5r/a+G9yR88iIFTC1qAUI7XZqItCzejAmnA=; b=YbUu+ENpzpn9PIHY35j/uzual8pIRv0pHI7+xyNiTSa1Do5dMIfCqlGfV4OY3SbnCh 8Onl3RKXoPCaDW02DVAY6BY9cnI1fnv40h6HP/hoTq5WKMFDiMlCB4RbbqTVAQnkPvHq NsentmI/EoU6RWM4oDB6ObABKNWOdGHxWIY8KgyyzQAMgBTBDtgEhjrwofHwgV2PiPRf onLtMmfUEaaQ0E+/s6kMDIsLuBDHUBnwhFfh3BQ2rKQUoPY5Nn5ResgwBIspTCDcAklZ xuv7VvAVbH1d38lRE4CG6i7Qzi2Mx1vaI7e0Yej5W4TVH9kXhxzlzEfv2BzISzh5K8WM ljlA== X-Gm-Message-State: AOAM530SuU/Mqu6JB53UGypoZWYzXgXEktM7Gn+jzBTep5JhS2gMxWWW w7jW26N6VoWouW1Q7C4fTeCUqg== X-Google-Smtp-Source: ABdhPJz4sRaH2NE7EHpuFl2Qbnsm3D+9OXA7lpSy0nnuyBMLUgDH0MiPSSk4AWAzv+XofyIVpgHhIw== X-Received: by 2002:ac8:698f:: with SMTP id o15mr25208850qtq.39.1617052531583; Mon, 29 Mar 2021 14:15:31 -0700 (PDT) Received: from brians-mbp.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id b10sm14095973qkg.50.2021.03.29.14.15.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Mar 2021 14:15:31 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9A6F6649-C8D7-4D41-840B-43A2FF15A11C" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Mon, 29 Mar 2021 17:15:29 -0400 In-Reply-To: <309D6418-5163-471C-A4CE-203D1DACB627@eggert.org> Cc: Randall Gellens , RFC Errata System , Hannes.Tschofenig@gmx.net, "Murray S. Kucherawy" , Francesca Palombini , Allison Mankin , Roger Marshall , ecrit@ietf.org To: Lars Eggert References: <309D6418-5163-471C-A4CE-203D1DACB627@eggert.org> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Ecrit] [Editorial Errata Reported] RFC8148 (6500) 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, 29 Mar 2021 21:15:40 -0000 --Apple-Mail=_9A6F6649-C8D7-4D41-840B-43A2FF15A11C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Lars We now know how to fix this, but I=E2=80=99m confused by this email. https://www.iana.org/assignments/media-types/media-types.xhtml = Has the following line for VEDS: EmergencyCallData.VEDS+xml application/EmergencyCallData.VEDS+xml = [RFC8148 ] The link for application/EmergencyCallData.VEDS+xml leads to = https://www.iana.org/assignments/media-types/application/EmergencyCallData= .VEDS+xml = Which contains (at the bottom): Change controller: The IESG Noting that it=E2=80=99s the same as the RFC, and therefore incorrect. What IANA page were you looking at? Brian > On Mar 29, 2021, at 12:35 PM, Lars Eggert wrote: >=20 > I didn=E2=80=99t see the change controller listed on the IANA page, = which is why I filed the errata. >=20 > --=20 > Sent from a mobile device; please excuse typos. >=20 >> On Mar 29, 2021, at 18:58, Randall Gellens = wrote: >>=20 >> =EF=BB=BFThis does seem like an obvious typo that was missed before = publication. I'm not sure if an errata is the best way of addressing = it, rather than having IANA update the MIME Media Type Registration for = application/EmergencyCall.VEDS+xml. >>=20 >> --Randall >>=20 >>> On 29 Mar 2021, at 1:37, RFC Errata System wrote: >>>=20 >>> The following errata report has been submitted for RFC8148, >>> "Next-Generation Vehicle-Initiated Emergency Calls". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>> https://www.rfc-editor.org/errata/eid6500 >>>=20 >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Lars Eggert >>>=20 >>> Section: 14.1 >>>=20 >>> Original Text >>> ------------- >>> Change controller: The IESG >>>=20 >>>=20 >>> Corrected Text >>> -------------- >>> Change controller: The IESG >>>=20 >>>=20 >>> Notes >>> ----- >>> The current text has the email address of the "IETF discuss" list = for the IESG, which is incorrect. >>>=20 >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party >>> can log in to change the status and edit the report, if necessary. >>>=20 >>> -------------------------------------- >>> RFC8148 (draft-ietf-ecrit-car-crash-23) >>> -------------------------------------- >>> Title : Next-Generation Vehicle-Initiated Emergency = Calls >>> Publication Date : May 2017 >>> Author(s) : R. Gellens, B. Rosen, H. Tschofenig >>> Category : PROPOSED STANDARD >>> Source : Emergency Context Resolution with Internet = Technologies >>> Area : Applications and Real-Time >>> Stream : IETF >>> Verifying Party : IESG >=20 --Apple-Mail=_9A6F6649-C8D7-4D41-840B-43A2FF15A11C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Lars

We = now know how to fix this, but I=E2=80=99m confused by this email.

https://www.iana.org/assignments/media-types/media-types.xhtml<= /a>
Has the following line for VEDS:
EmergencyCallData.VEDS+xml application/EmergencyCallData.VEDS+xml [RFC8148]

The link for = application/EmergencyCallData.VEDS+xml leads to
https://www.iana.org/assignments/media-types/application/Emerge= ncyCallData.VEDS+xml

Which contains (at the bottom):
Change controller: The IESG <ietf&ietf.org>



Noting that it=E2=80=99s the same as the RFC, and therefore = incorrect.

What = IANA page were you looking at?


Brian


On Mar = 29, 2021, at 12:35 PM, Lars Eggert <lars@eggert.org> wrote:

I = didn=E2=80=99t see the change controller listed on the IANA page, which = is why I filed the errata.

--
Sent from a mobile device; please excuse typos.

On Mar = 29, 2021, at 18:58, Randall Gellens <rg+ietf@coretechnologyconsulting.com> wrote:

=EF=BB=BFThis does seem like an obvious typo = that was missed before publication.  I'm not sure if an errata is = the best way of addressing it, rather than having IANA update the MIME = Media Type Registration for application/EmergencyCall.VEDS+xml.

--Randall

On 29 Mar 2021, at 1:37, = RFC Errata System wrote:

The following = errata report has been submitted for RFC8148,
"Next-Generation Vehicle-Initiated Emergency Calls".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6500
--------------------------------------
Type: = Editorial
Reported by: Lars Eggert = <lars@eggert.org>

Section: 14.1

Original Text
-------------
    Change controller:  The IESG = <ietf@ietf.org>


Corrected Text
--------------
=     Change controller:  The IESG = <iesg@ietf.org>


Notes-----
The current text has the email address = of the "IETF discuss" list for the IESG, which is incorrect.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, = please
use "Reply All" to discuss whether it should be = verified or
rejected. When a decision is reached, the = verifying party
can log in to change the status and edit = the report, if necessary.

--------------------------------------
RFC8148 = (draft-ietf-ecrit-car-crash-23)
--------------------------------------
Title =             &n= bsp; : Next-Generation Vehicle-Initiated Emergency Calls
Publication Date    : May 2017
Author(s) =           : R. = Gellens, B. Rosen, H. Tschofenig
Category =            : = PROPOSED STANDARD
Source =             &n= bsp;: Emergency Context Resolution with Internet Technologies
Area =             &n= bsp;  : Applications and Real-Time
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG


= --Apple-Mail=_9A6F6649-C8D7-4D41-840B-43A2FF15A11C-- From nobody Mon Mar 29 23:54:54 2021 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 6E67E3A0BC2 for ; Mon, 29 Mar 2021 23:54:51 -0700 (PDT) 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=eggert.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 9bUFQAfuG4Vr for ; Mon, 29 Mar 2021 23:54:47 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 1194D3A0BC1 for ; Mon, 29 Mar 2021 23:54:47 -0700 (PDT) Received: from [IPv6:2a00:ac00:4000:400:1894:d982:c139:2ff9] (unknown [IPv6:2a00:ac00:4000:400:1894:d982:c139:2ff9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 7AE25600076; Tue, 30 Mar 2021 09:54:35 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1617087275; bh=09SgM5ERX4072t7IcFEY6+LFQxaSSSXODq2YE5G1XD8=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=kkZlDrQjmp+SBrwsXdQBda3siaVy8zZjS9RfDNOTdQ8Ois9Y9thQckP3FD/YKRSBF U12c4IPZXF3CYPvVBkXNL3rVmU7SGxc56qGSP1r6wBxF8e58f6qdd3CFith1KBaTQP or6mUhtuxnihAtFlfxb8bfR2+tE6Le0KJmeMwSc4= From: Lars Eggert Message-Id: <4B0F8379-A1A5-4A1B-9650-FEFF62BF9B34@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_2A3D60D1-3C81-4909-9735-5A0419E0265D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Tue, 30 Mar 2021 09:54:35 +0300 In-Reply-To: Cc: Randall Gellens , RFC Errata System , Hannes Tschofenig , "Murray S. Kucherawy" , Francesca Palombini , Allison Mankin , Roger Marshall , ecrit@ietf.org To: Brian Rosen References: <309D6418-5163-471C-A4CE-203D1DACB627@eggert.org> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-MailScanner-ID: 7AE25600076.A123D X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Ecrit] [Editorial Errata Reported] RFC8148 (6500) 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, 30 Mar 2021 06:54:52 -0000 --Apple-Mail=_2A3D60D1-3C81-4909-9735-5A0419E0265D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, On 2021-3-30, at 0:15, Brian Rosen wrote: > = https://www.iana.org/assignments/media-types/application/EmergencyCallData= .VEDS+xml >=20 > Which contains (at the bottom): > Change controller: The IESG >=20 > Noting that it=E2=80=99s the same as the RFC, and therefore incorrect. >=20 > What IANA page were you looking at? that one, but I must have missed this. (Maybe it was strategically below = the fold on my phone screen...) Thanks, Lars --Apple-Mail=_2A3D60D1-3C81-4909-9735-5A0419E0265D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmBiyysACgkQVLXDCb9w wVfcjQ//cUou9K5Vu8K5p37EF7nQ6wrX67bGHP+LDLxzo1yhFm4yv8TFHd7Erkns J2lSFp5H1OqXoCA8maukzYF7r7V/AMcDzMH6upxxY1MJtroei0aPPQms4J0guu35 us4AzwaaFg4JLSnr2/aQIDJLofUiI04KsSgO9pe4qstyKj5N21uWnrlbTisR+ERW HVyr+b5gaj6UXBl42u0HFwHrODklI6KOPYAkDSnKi0KE92G7a7bKtY5SLVFSaoA5 79ovx9HkYawYBp20AJXTTJ/Q+pRloPkwMTjVQMX05HLrqsbpbd2QIiUD79nu5jRi kv2O/3P5rAJELSvv1uTmKL3y7M2aWuA4qJeivoIWLKIkKzijZLkS5FEPFD6QrrVU d0apVOpRCL71ixY8jo9eHgWYM1c1U/Ki2nbDy+mZ5DObBcx/yzbGxSjJggRI5bYO Flet4jjMBSlWEDx7us3x7o7K4JYwsW+ZTFm5Lq+yTqjG2EECCkA0I4UMdg9GYXlM THpur5KWLHf1AluWEDVZRbPJLkAk4W8oYnQatiMo9dmAQO13hNIDtTnquS5Tj22B OJpULzXx5hmc6jbbh1IrgdvyTExoi9+q5n/SsDteU3Xb8hDSpg0lE1eLvUznah2s zUB7Z6YXv6iVnQTJxvAv7HjQFuM//avPn/xe2Ll72kQvfxK6YvE= =cBMY -----END PGP SIGNATURE----- --Apple-Mail=_2A3D60D1-3C81-4909-9735-5A0419E0265D-- From nobody Tue Mar 30 13:04:55 2021 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 B5F943A2060; Tue, 30 Mar 2021 13:04:50 -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: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-ecrit-location-profile-registry-policy@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, rfc-editor@rfc-editor.org, roger.marshall@comtechtel.com, superuser@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <161713469066.32269.15942283829364333546@ietfa.amsl.com> Date: Tue, 30 Mar 2021 13:04:50 -0700 Archived-At: Subject: [Ecrit] Protocol Action: 'Changing the LoST Location Profile Registry Policy' to Proposed Standard (draft-ietf-ecrit-location-profile-registry-policy-02.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, 30 Mar 2021 20:04:51 -0000 The IESG has approved the following document: - 'Changing the LoST Location Profile Registry Policy' (draft-ietf-ecrit-location-profile-registry-policy-02.txt) as Proposed Standard This document is the product of the Emergency Context Resolution with Internet Technologies Working Group. The IESG contact persons are Murray Kucherawy and Francesca Palombini. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-location-profile-registry-policy/ Technical Summary This document changes the policy of the Location-to-Service Translation (LoST) Location Profile registry established by RFC5222 from Standards Action to Specification Required. This allows standards development organizations (SDOs) other than the IETF to add new values. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality Nothing was noted. Consensus was straightforward, including several participants (mostly tied to NENA) provided a positive response for the question of whether this draft should be adopted as a WG item, with a couple of participants doing a thorough review with comments as noted in the Acknowledgements section. Personnel Who is the Document Shepherd? Roger Marshall Who is the Responsible Area Director? Murray Kucherawy