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

Benjamin Kaduk <kaduk@mit.edu> Tue, 16 March 2021 17:39 UTC

Return-Path: <kaduk@mit.edu>
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 <kaduk@mit.edu>
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: "Murray S. Kucherawy" <superuser@gmail.com>, "last-call@ietf.org" <last-call@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>, "secdir@ietf.org" <secdir@ietf.org>
Message-ID: <20210316173921.GG79563@kduck.mit.edu>
References: <161591246412.5771.17798271339560020312@ietfa.amsl.com> <CAL0qLwbAmYbX9A3f+okpum0Gz6hKhZz-_CPxhsu-nahFvVO7Bg@mail.gmail.com> <SN6PR13MB2334DCB45EB76B47C19AFDEE856B9@SN6PR13MB2334.namprd13.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <SN6PR13MB2334DCB45EB76B47C19AFDEE856B9@SN6PR13MB2334.namprd13.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/m2gjJ7wBMzFBUt2gzXwx02G-UF0>
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: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=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 <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-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 <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
> https://www.ietf.org/mailman/listinfo/last-call