Re: [secdir] Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01

Linda Dunbar <linda.dunbar@futurewei.com> Fri, 19 March 2021 18:09 UTC

Return-Path: <linda.dunbar@futurewei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@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 <linda.dunbar@futurewei.com>
To: Randall Gellens <rg+ietf@randy.pensive.org>
CC: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org" <draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org>, "ecrit@ietf.org" <ecrit@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "Murray S. Kucherawy" <superuser@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>
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: <SN6PR13MB23347EAFEEBBF83BA1827A4C85689@SN6PR13MB2334.namprd13.prod.outlook.com>
References: <161591246412.5771.17798271339560020312@ietfa.amsl.com> <161591246412.5771.17798271339560020312@ietfa.amsl.com> <161591246412.5771.17798271339560020312@ietfa.amsl.com> <CAL0qLwbAmYbX9A3f+okpum0Gz6hKhZz-_CPxhsu-nahFvVO7Bg@mail.gmail.com> <CAL0qLwbAmYbX9A3f+okpum0Gz6hKhZz-_CPxhsu-nahFvVO7Bg@mail.gmail.com> <CAL0qLwbAmYbX9A3f+okpum0Gz6hKhZz-_CPxhsu-nahFvVO7Bg@mail.gmail.com> <SN6PR13MB2334DCB45EB76B47C19AFDEE856B9@SN6PR13MB2334.namprd13.prod.outlook.com> <SN6PR13MB2334DCB45EB76B47C19AFDEE856B9@SN6PR13MB2334.namprd13.prod.outlook.com> <SN6PR13MB2334DCB45EB76B47C19AFDEE856B9@SN6PR13MB2334.namprd13.prod.outlook.com> <20210316173921.GG79563@kduck.mit.edu> <20210316173921.GG79563@kduck.mit.edu> <CAL0qLwZAusJnQrMeKrAkkij7A2WMnDYBTZ6mKr9gadWbyA4qHQ@mail.gmail.com> <CAL0qLwZAusJnQrMeKrAkkij7A2WMnDYBTZ6mKr9gadWbyA4qHQ@mail.gmail.com> <CAL0qLwZAusJnQrMeKrAkkij7A2WMnDYBTZ6mKr9gadWbyA4qHQ@mail.gmail.com> <C443EB5E-89B3-4777-90AB-B063C1240A8A@coretechnologyconsulting.com> <C443EB5E-89B3-4777-90AB-B063C1240A8A@coretechnologyconsulting.com> <C443EB5E-89B3-4777-90AB-B063C1240A8A@coretechnologyconsulting.com> <C443EB5E-89B3-4777-90AB-B063C1240A8A@coretechnologyconsulting.com> <C443EB5E-89B3-4777-90AB-B063C1240A8A@coretechnologyconsulting.com> <EAE1C85A-896B-4C26-AE3E-706D3F4EAEE8@randy.pensive.org>
In-Reply-To: <EAE1C85A-896B-4C26-AE3E-706D3F4EAEE8@randy.pensive.org>
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: <SA1PR13MB49588C945D1F575B121C1AE785689@SA1PR13MB4958.namprd13.prod.outlook.com>
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: ei42XJvMAT6GmTE+Wsa3uiRYANAemshBqh7zu8/vAVMAT49K0I+2GjsmmMLJBQxVHDLv5gYm96A+tK1UTXS/vd39WJ/elzH8IVGCA5cPSItpUrrkO8oxK6RN4abxQdduXaaQTq5CbbDgTVPielCQKh/ceoX1aMTgEVr/0aZd7CTrIqsSZmoBT3EhOnYyE6ebX3frbHnuYa13U3SyX4lTXXLKL/IiKOGgRdD5MHj+VAZ7b9A/h3Bm4tS+OkbZYjKqUeudKl+fEsqpvpmgRVafe61frs1krovShUb6iMmu1M/UvpJE/dpMHs/EuwhHIGkzC3dLElAZnw9NqPkH6RqCWzBC6XeJpdlGTBOZjEzgDlAFlGCpzCKZ7KCkzeNeOmL8uUIh5DzGiMazsRqQ7rk7y+Mw59/L9paOfr9oj5KrRM4628ojQUWfbPY94l3CWre3OmCScXBiX67TxXuKgVzf5Ag9c0SZMiVYO5VsA5kvuwgLF56bgWMCZKAisnge2ELimAruzZS9kAhvu33zR9R811j/Cfvdd4CNHMcslk6xdI/8G2FK7eQbLqsD1F/Xdr+wIYBlkL+LIiCHrijMMTjcvRYU6BxW8u6KnSeOBaEWdyfP0l+9A6715/owzxhnzQkl6e8U95LZ2Cav0Fg4qSQTXRae7Jm8qAkdqZ08sqvVxNWTuFM5BcddYso1c+fMXZoa1D1BI2VG36Se4VlIQIbdwY7aOJq1vev9wFnRDA8mg/cNbsy8Br69carc8n/ye1EM594fByK5694WGzPIs5pxWp37hfNS2BDxCJvTByXBRNTnz6Dj9Q3TJ+S6VswmJ1wQaXZ318NdCtf+QlQhrUfuZqX6SqEfOaMKiN/AysRL8ulb1otkIZZAwTxjasJe9bT1ekdByMQ9rUBCW4IXMNQwxvuks9+YQF6tlVyOBHesbD4HEbrZpSY3oZKa9a+CQosI0MPa4ybmuaJOyPQo2f5MvcLuixi9wDCc69wpQGqPDxiQfwWzqDCZW3/eJfxF6a/Cmf5ful9J1WFapvaN1dDDpIOOvJOfBXeehaAyXT6qtEaLadANTr7yyI5BGvqa0c4/b6TGI2oiur2srI0rheceYjVPGgG7jh73fCEq0Ej4LO47bYj8uuB3zSjWFrca9vGELla2jYc1zcBz3KoBztBhl9/QLKSOT/2H6NPoGnTF3wWwuKAtQnziRbMtjtsno5d/K0tbW9dpg4ghL86AjpN1VkfNEB+mdyD8k8zcbnjA3T0zEQkkkVb5PBmkwkQVaiIHy2155VnIg/RLT9iSIxSYmc43qLuxWA+YrNF4iY7RKx0=
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: <https://mailarchive.ietf.org/arch/msg/secdir/kS4hDm7_tSo1_NBP_s5RqsTTg-8>
Subject: Re: [secdir] Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Mar 2021 18:09:21 -0000

Randall,

No, I don't have any more comments. Replies are good.

Linda

From: Randall Gellens <rg+ietf@randy.pensive.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-policy.all@ietf.org; ecrit@ietf.org; last-call@ietf.org; Murray S. Kucherawy <superuser@gmail.com>; Benjamin Kaduk <kaduk@mit.edu>
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01


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<mailto:Ecrit@ietf.org>
https://www.ietf.org/mailman/listinfo/ecrit<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fecrit&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C3fc2f2f9e09d47254b6e08d8eb003d7e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637517733570121740%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6qoRa9Zca4q88pkoc43X8dri9z8jHolvT2LafMfzHx4%3D&reserved=0>

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<mailto:last-call@ietf.org>
https://www.ietf.org/mailman/listinfo/last-call<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flast-call&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C3fc2f2f9e09d47254b6e08d8eb003d7e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637517733570121740%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=y5mrMsS2CkIDOgVPOsa%2FuzjcwLWQlLYMHoqMcVuJ0YI%3D&reserved=0>

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<mailto: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<mailto: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<mailto:Ecrit@ietf.org>
https://www.ietf.org/mailman/listinfo/ecrit<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fecrit&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C3fc2f2f9e09d47254b6e08d8eb003d7e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637517733570131734%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=T7BQ5uuEokV465Z5eMqAn7nOmXk7oFtBpqAjQqOAsHs%3D&reserved=0>

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<mailto: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<mailto:last-call@ietf.org>
https://www.ietf.org/mailman/listinfo/last-call<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flast-call&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C3fc2f2f9e09d47254b6e08d8eb003d7e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637517733570131734%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qpsbCh4mM%2F0lO2vO0qhBU%2F0VLrFxaaUbJB6%2Bb2oddm4%3D&reserved=0>

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 published specification"?



Linda



From: Murray S. Kucherawy <superuser@gmail.com<mailto:superuser@gmail.com>>
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>
Cc: secdir@ietf.org<mailto:secdir@ietf.org>; draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org<mailto:draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org>; ecrit@ietf.org<mailto:ecrit@ietf.org>; last-call@ietf.org<mailto: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 <noreply@ietf.org<mailto: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 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 published specification"?



Linda



From: Murray S. Kucherawy <superuser@gmail.com<mailto:superuser@gmail.com>>
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>
Cc: secdir@ietf.org<mailto:secdir@ietf.org>; draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org<mailto:draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org>; ecrit@ietf.org<mailto:ecrit@ietf.org>; last-call@ietf.org<mailto: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 <noreply@ietf.org<mailto: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<mailto:Ecrit@ietf.org>
https://www.ietf.org/mailman/listinfo/ecrit<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fecrit&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C3fc2f2f9e09d47254b6e08d8eb003d7e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637517733570141734%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=65MgTiR1BI%2FoDvJIRyB3r2Zun%2BnbuYfO1zUkgOZQgEg%3D&reserved=0>

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 published specification"?



Linda



From: Murray S. Kucherawy <superuser@gmail.com<mailto:superuser@gmail.com>>
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>
Cc: secdir@ietf.org<mailto:secdir@ietf.org>; draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org<mailto:draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org>; ecrit@ietf.org<mailto:ecrit@ietf.org>; last-call@ietf.org<mailto: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 <noreply@ietf.org<mailto: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<mailto:last-call@ietf.org>
https://www.ietf.org/mailman/listinfo/last-call<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flast-call&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C3fc2f2f9e09d47254b6e08d8eb003d7e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637517733570141734%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tsZ4%2BOwYQFvY9sNnSMEV6bXrsFqEbaI%2Bjf5xx6vL5Fk%3D&reserved=0>

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-profiles.xhtml<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Flost-location-profiles%2Flost-location-profiles.xhtml&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C3fc2f2f9e09d47254b6e08d8eb003d7e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637517733570151723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t4tc%2Fv6ySPRZJsw%2F64zwQysDzQapNKl7E9KbadD6IR4%3D&reserved=0>)
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 superuser@gmail.com<mailto:superuser@gmail.com>
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>
Cc: secdir@ietf.org<mailto:secdir@ietf.org>; draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org<mailto:draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org>; ecrit@ietf.org<mailto:ecrit@ietf.org>; last-call@ietf.org<mailto: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 <noreply@ietf.org<mailto:noreply@ietf.org<mailto:noreply@ietf.org%3cmailto: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<mailto:last-call@ietf.org>
https://www.ietf.org/mailman/listinfo/last-call<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flast-call&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C3fc2f2f9e09d47254b6e08d8eb003d7e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637517733570151723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=P4C9q4hAsQK6yfUqixeuqXzL4JAePs0W42KA67qMNXE%3D&reserved=0>

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-profiles.xhtml<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Flost-location-profiles%2Flost-location-profiles.xhtml&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C3fc2f2f9e09d47254b6e08d8eb003d7e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637517733570161717%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4F3dz6ntJ4IgAeY6%2BaEPCljCEdmXYorJf8yT%2FY48arI%3D&reserved=0>)
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 superuser@gmail.com<mailto:superuser@gmail.com>
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>
Cc: secdir@ietf.org<mailto:secdir@ietf.org>; draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org<mailto:draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org>; ecrit@ietf.org<mailto:ecrit@ietf.org>; last-call@ietf.org<mailto: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 <noreply@ietf.org<mailto:noreply@ietf.org<mailto:noreply@ietf.org%3cmailto: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<mailto:last-call@ietf.org>
https://www.ietf.org/mailman/listinfo/last-call<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flast-call&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C3fc2f2f9e09d47254b6e08d8eb003d7e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637517733570161717%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Mhjy0q5t1JxPsk4%2B0mwAwgZQGaQvc2bZG82o3tVv2Bo%3D&reserved=0>

--
last-call mailing list
last-call@ietf.org<mailto:last-call@ietf.org>
https://www.ietf.org/mailman/listinfo/last-call<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flast-call&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C3fc2f2f9e09d47254b6e08d8eb003d7e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637517733570171712%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CqLyzU8fYIOJBECloFu8Zfd6UKKhpko0m8TkjXaPPyI%3D&reserved=0>

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<mailto: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 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 <linda.dunbar@futurewei.com<mailto: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 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<mailto:Ecrit@ietf.org>
https://www.ietf.org/mailman/listinfo/ecrit<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fecrit&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C3fc2f2f9e09d47254b6e08d8eb003d7e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637517733570171712%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=y6ECU6a%2B9PGgLbN8VxN9yDwXy2irkI6nZwBH2bw1ELI%3D&reserved=0>

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<mailto: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 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<mailto:last-call@ietf.org>
https://www.ietf.org/mailman/listinfo/last-call<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flast-call&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C3fc2f2f9e09d47254b6e08d8eb003d7e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637517733570181706%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5u4HMwhR40URJ20%2BKgqJKnnOV%2FBsbCt3t64X98%2FByG8%3D&reserved=0>

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<mailto:Ecrit@ietf.org>
https://www.ietf.org/mailman/listinfo/ecrit<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fecrit&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C3fc2f2f9e09d47254b6e08d8eb003d7e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637517733570181706%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lnyzB47GbuU9VpfIZ6zVDozpGy7uwelm7WsK9jZcR0I%3D&reserved=0>

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<mailto:last-call@ietf.org>
https://www.ietf.org/mailman/listinfo/last-call<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flast-call&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C3fc2f2f9e09d47254b6e08d8eb003d7e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637517733570191704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wxe8Z7PdL7KP3qSlmX9wW4IjdNNh06USCwjI64Te%2BWU%3D&reserved=0>