From nobody Tue Sep 22 10:33:03 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C00A3A09C1; Tue, 22 Sep 2020 10:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2kAKp_yB_obg; Tue, 22 Sep 2020 10:32:57 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F103A03FC; Tue, 22 Sep 2020 10:32:57 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 39C69F40788; Tue, 22 Sep 2020 10:32:49 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, ecrit@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200922173249.39C69F40788@rfc-editor.org> Date: Tue, 22 Sep 2020 10:32:49 -0700 (PDT) Archived-At: Subject: [Ecrit] =?utf-8?q?RFC_8876_on_Non-interactive_Emergency_Calls?= 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, 22 Sep 2020 17:32:58 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8876 Title: Non-interactive Emergency Calls Author: B. Rosen, H. Schulzrinne, H. Tschofenig, R. Gellens Status: Standards Track Stream: IETF Date: September 2020 Mailbox: br@brianrosen.net, hgs+ecrit@cs.columbia.edu, Hannes.Tschofenig@gmx.net, rg+ietf@coretechnologyconsulting.com Pages: 25 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ecrit-data-only-ea-22.txt URL: https://www.rfc-editor.org/info/rfc8876 DOI: 10.17487/RFC8876 Use of the Internet for emergency calling is described in RFC 6443, 'Framework for Emergency Calling Using Internet Multimedia'. In some cases of emergency calls, the transmission of application data is all that is needed, and no interactive media channel is established: a situation referred to as 'non-interactive emergency calls', where, unlike most emergency calls, there is no two-way interactive media such as voice or video or text. This document describes use of a SIP MESSAGE transaction that includes a container for the data based on the Common Alerting Protocol (CAP). That type of emergency request does not establish a session, distinguishing it from SIP INVITE, which does. Any device that needs to initiate a request for emergency services without an interactive media channel would use the mechanisms in this document. This document is a product of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Sep 25 09:09:10 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DE53A118C for ; Fri, 25 Sep 2020 09:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RipdX5IEDMaF for ; Fri, 25 Sep 2020 09:09:07 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0313A1189 for ; Fri, 25 Sep 2020 09:09:07 -0700 (PDT) Received: from [169.254.154.132] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 25 Sep 2020 09:09:06 -0700 From: "Randall Gellens" To: ecrit@ietf.org Date: Fri, 25 Sep 2020 09:09:05 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <5241D8A2-8F94-4D98-A7DD-119BEE92D081@coretechnologyconsulting.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Ecrit] Short standards-track doc to add two entries to LoST profile registry 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, 25 Sep 2020 16:09:09 -0000 Hi ECRIT, I have a short draft that changes the policy of the LoST Location = Profile registry from Standards Action to Specification Required (so = NENA can add values): https://www.ietf.org/id/draft-ecrit-location-profile-registry-policy-00.t= xt (The registry is at = https://www.iana.org/assignments/lost-location-profiles/lost-location-pro= files.xhtml). Comments are requested. --Randall From nobody Fri Sep 25 09:16:44 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB863A1197 for ; Fri, 25 Sep 2020 09:16:42 -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 PR6WcDDPFy6k for ; Fri, 25 Sep 2020 09:16:41 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id E4B673A119A for ; Fri, 25 Sep 2020 09:16:40 -0700 (PDT) Received: from [169.254.154.132] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 25 Sep 2020 09:16:40 -0700 From: "Randall Gellens" To: ecrit@ietf.org Date: Fri, 25 Sep 2020 09:16:39 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <795B3FC5-EDE8-49C2-96D9-EE785050DC2B@coretechnologyconsulting.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Ecrit] Changing the LoST Location Profile registry from Standards Action to Specification Required 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, 25 Sep 2020 16:16:43 -0000 Hi ECRIT, I have a short draft that changes the policy of the LoST Location = Profile registry from Standards Action to Specification Required (so = NENA can add values): https://www.ietf.org/id/draft-ecrit-location-profile-registry-policy-00.t= xt (The registry is at = https://www.iana.org/assignments/lost-location-profiles/lost-location-pro= files.xhtml). Comments are requested. --Randall From nobody Fri Sep 25 11:02:38 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165DE3A13FD for ; Fri, 25 Sep 2020 11:02:36 -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 5Gdkus_Y1gWZ for ; Fri, 25 Sep 2020 11:02:34 -0700 (PDT) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 6C7DD3A13FC for ; Fri, 25 Sep 2020 11:02:34 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id n61so3106319ota.10 for ; Fri, 25 Sep 2020 11:02:34 -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=5kg9QxJbDRIJY+Kjm+gNUNLqtE1EMNg9mZfxIWU1GQ8=; b=KSW3GjIXyvaxd8tTcfos4zfQfWE+8joK6Hj5EBv6OG1j3FXQvXrntcmN+A8YLJl3X/ Ss4c4xJigiRmCSnNFjEpAi4pJcomwvddh0mrTmjFg7bsATkPcAUA8nDjdc4/KVN2dBfY t0yiz65Zd46bquQk7FZaU/UHfZDkkKph0wbCaPl6FpJwwbUkSoQP1KRQ4OKZkY0gKfQ1 f/fIakNM5QoGxB6hxUKuhRYqRrLEU4qgqvnkuIwUBJRmxja2jFvDOGmxJ/pizF/K5xX8 vVBjQpws3MHwa9YdmzCbMIXKDuo6qgnmiti3Le7XoEme+Wk8lZVBqEA5h6izO5T+RbEi gcXA== 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=5kg9QxJbDRIJY+Kjm+gNUNLqtE1EMNg9mZfxIWU1GQ8=; b=OYZMzozuqaqPLy7fZAAp/q3C+z+k2HA1WBJEpS+snCC+4GJ9vhjqKOZjEMJWnWXDRZ RL451Y8dyDAzwvs4WEck3X1QobDWCdVy9UTtcc9+4tZURxyKG6trtRsJ3oAP1i9nYI8e QOVhEWdPBtePTvSTP/Q8LKqUGoMfCoTUH0tbbODvVnXHC4jGaaTUlhux9ozmoCa+Py17 hC5u4jCWbPZHL+63RZdSsekW393UAK2mWktdDFIDZJeuF2ceJ/danbmFhUXIl7AwsKZV w6NL/OrfcIdzkQwx21vssbJMUWS6WsBrmv9j2THYpDbqj2JgYTHsqgmmDLJ7oI9SvWuv PNRQ== X-Gm-Message-State: AOAM533i+N3yQ1UfhxAjQHGMgloWCsg+isNc3hfoOC0qAhWXvtt9p6Bn GUAgltS4DDqxrP1u2ltgn1PTCbdtbd/Ng7yUgE378Fh1cLztWQ== X-Google-Smtp-Source: ABdhPJyFdhOI97fW0Fll1zsPCNSM0w0s1yrujLHKCCbUUvPLv+eHhy73YFhg/0ytKPOylfEjGYKzwnVEzJiuA6NuYA4= X-Received: by 2002:a9d:7d93:: with SMTP id j19mr1166547otn.49.1601056952158; Fri, 25 Sep 2020 11:02:32 -0700 (PDT) MIME-Version: 1.0 References: <795B3FC5-EDE8-49C2-96D9-EE785050DC2B@coretechnologyconsulting.com> In-Reply-To: <795B3FC5-EDE8-49C2-96D9-EE785050DC2B@coretechnologyconsulting.com> From: Ted Hardie Date: Fri, 25 Sep 2020 11:02:06 -0700 Message-ID: To: Randall Gellens Cc: ecrit@ietf.org Content-Type: multipart/alternative; boundary="000000000000e60bde05b0271e2b" Archived-At: Subject: Re: [Ecrit] Changing the LoST Location Profile registry from Standards Action to Specification Required 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, 25 Sep 2020 18:02:36 -0000 --000000000000e60bde05b0271e2b Content-Type: text/plain; charset="UTF-8" Hi Randy, Thanks for sharing the document. A couple of suggestions: a citation to RFC 8126 would be useful, since "specification required" is defined there. I'd also suggest that you change the IANA considerations in two ways. At the moment, you name an expert reviewer, which is a bit out of the ordinary; I'd suggest removing that. Second, you currently have this text in the introduction: This document changes the registry policy to Specification Required, allowing other SDOs such as NENA to add values. "Specification required" is actually a good bit more open than this, as it allows the expert to permit informal specifications (like internet-drafts). If this change is really specific to NENA and similar emergency services bodies, I'd suggest moving this to the IANA considerations and making that an explicit instruction to the expert. That would permit standards action plus those SDOs but would support the expert continuing to limit the registry beyond those uses. best regards, Ted Hardie On Fri, Sep 25, 2020 at 9:16 AM Randall Gellens < rg+ietf@coretechnologyconsulting.com> wrote: > Hi ECRIT, > > I have a short draft that changes the policy of the LoST Location > Profile registry from Standards Action to Specification Required (so > NENA can add values): > > https://www.ietf.org/id/draft-ecrit-location-profile-registry-policy-00.txt > > (The registry is at > > https://www.iana.org/assignments/lost-location-profiles/lost-location-profiles.xhtml > ). > > Comments are requested. > > --Randall > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > --000000000000e60bde05b0271e2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Randy,

Thanks for sharing= the document.=C2=A0=C2=A0 A couple of suggestions:=C2=A0 a citation to RFC= 8126 would be useful, since "specification required" is defined = there.=C2=A0 I'd also suggest that you change the IANA considerations i= n two ways.=C2=A0 At the moment, you=C2=A0 name an expert reviewer, which i= s a bit out of the ordinary; I'd suggest removing that.=C2=A0 Second, y= ou currently have this text in the introduction:

<= pre> This document changes the registry policy to Specification Required= ,
allowing other SDOs such as NENA to add values.

"= ;Specification required" is actually a good bit more open than this, a= s it allows the expert to permit informal specifications (like internet-dra= fts).=C2=A0 If this change is really specific to NENA and similar emergency= services bodies, I'd suggest moving this to the IANA considerations an= d making that an explicit instruction to the expert.=C2=A0 That would permi= t standards action plus those SDOs but would support the expert continuing = to limit the registry beyond those uses.=C2=A0

best regards,

Ted Hardie

On Fri, Sep 25= , 2020 at 9:16 AM Randall Gellens <rg+ietf@coretechnologyconsulting.com> wrote:
Hi ECRIT,

I have a short draft that changes the policy of the LoST Location
Profile registry from Standards Action to Specification Required (so
NENA can add values):

https://www.ietf.org/id/d= raft-ecrit-location-profile-registry-policy-00.txt

(The registry is at
https://www.iana= .org/assignments/lost-location-profiles/lost-location-profiles.xhtml).<= br>
Comments are requested.

--Randall

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
--000000000000e60bde05b0271e2b-- From nobody Fri Sep 25 14:15:21 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351303A09C0 for ; Fri, 25 Sep 2020 14:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.574 X-Spam-Level: * X-Spam-Status: No, score=1.574 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_RELAY_MUA_TO_MX=3.473, 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 EC8bRcGP90XJ for ; Fri, 25 Sep 2020 14:15:18 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id E69E83A0E4B for ; Fri, 25 Sep 2020 14:14:47 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 25 Sep 2020 14:14:47 -0700 From: "Randall Gellens" To: "Ted Hardie" Cc: ecrit@ietf.org Date: Fri, 25 Sep 2020 14:14:46 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <15F97CDF-70CC-4612-B29E-80B43ED2DB35@coretechnologyconsulting.com> In-Reply-To: References: <795B3FC5-EDE8-49C2-96D9-EE785050DC2B@coretechnologyconsulting.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_BE760295-339E-4006-9666-F7977215C973_=" Embedded-HTML: [{"HTML":[927, 2643], "plain":[579, 1743], "uuid":"E65D6A35-8278-465F-A385-3E2EB79D5E17"}] Archived-At: Subject: Re: [Ecrit] Changing the LoST Location Profile registry from Standards Action to Specification Required 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, 25 Sep 2020 21:15:19 -0000 --=_MailMate_BE760295-339E-4006-9666-F7977215C973_= Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable Hi Ted, Thanks for your review, I appreciate it. If I understand, you're = suggesting that in the IANA Considerations section it not name the = expert reviewer (I thought I needed to), and to replace "The reviewer = should use a criteria of a clear need and unambiguous definition for any = new value" with "The reviewer should verify that any proposed value is = specified by NENA or another SDO for emergency services, and meets a = criteria of a clear need and unambiguous definition"? And also replace = RFC 5226 with RFC 8126. --Randall On 25 Sep 2020, at 11:02, Ted Hardie wrote: > Hi Randy, > > Thanks for sharing the document. A couple of suggestions: a = > citation to > RFC 8126 would be useful, since "specification required" is defined = > there. > I'd also suggest that you change the IANA considerations in two ways. = > At > the moment, you name an expert reviewer, which is a bit out of the > ordinary; I'd suggest removing that. Second, you currently have this = > text > in the introduction: > > This document changes the registry policy to Specification = > Required, > allowing other SDOs such as NENA to add values. > > "Specification required" is actually a good bit more open than this, = > as it > allows the expert to permit informal specifications (like > internet-drafts). If this change is really specific to NENA and = > similar > emergency services bodies, I'd suggest moving this to the IANA > considerations and making that an explicit instruction to the expert. = > That > would permit standards action plus those SDOs but would support the = > expert > continuing to limit the registry beyond those uses. > > best regards, > > Ted Hardie > > On Fri, Sep 25, 2020 at 9:16 AM Randall Gellens < > rg+ietf@coretechnologyconsulting.com> wrote: > >> Hi ECRIT, >> >> I have a short draft that changes the policy of the LoST Location >> Profile registry from Standards Action to Specification Required (so >> NENA can add values): >> >> https://www.ietf.org/id/draft-ecrit-location-profile-registry-policy-0= 0.txt >> >> (The registry is at >> >> https://www.iana.org/assignments/lost-location-profiles/lost-location-= profiles.xhtml >> ). >> >> Comments are requested. >> >> --Randall >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> --=_MailMate_BE760295-339E-4006-9666-F7977215C973_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Hi Ted,

Thanks for your review, I appreciate it. If I understand= , you're suggesting that in the IANA Considerations section it not name t= he expert reviewer (I thought I needed to), and to replace "The reviewer = should use a criteria of a clear need and unambiguous definition for any = new value" with "The reviewer should verify that any proposed value is sp= ecified by NENA or another SDO for emergency services, and meets a criter= ia of a clear need and unambiguous definition"? And also replace RFC 5226= with RFC 8126.

--Randall

On 25 Sep 2020, at 11:02, Ted Hardie wrote:

Hi Randy,

Thanks for sharing= the document.=C2=A0=C2=A0 A couple of suggestions:=C2=A0 a citation to R= FC 8126 would be useful, since "specification required" is defi= ned there.=C2=A0 I'd also suggest that you change the IANA considerat= ions in two ways.=C2=A0 At the moment, you=C2=A0 name an expert reviewer,= which is a bit out of the ordinary; I'd suggest removing that.=C2=A0= Second, you currently have this text in the introduction:

= 
   This document changes the registry  policy to Specific=
ation Required, 
   allowing other SDOs such as NENA to add values.
"Specification required" is actually a good bit more= open than this, as it allows the expert to permit informal specification= s (like internet-drafts).=C2=A0 If this change is really specific to NENA= and similar emergency services bodies, I'd suggest moving this to th= e IANA considerations and making that an explicit instruction to the expe= rt.=C2=A0 That would permit standards action plus those SDOs but would su= pport the expert continuing to limit the registry beyond those uses.=C2=A0=

best regards,

Ted= Hardie

On Fri, Sep 25, 2020 at 9:16 AM Randall Gellens <rg+ietf@coretechn= ologyconsulting.com> wrote:
Hi ECRIT,

I have a short draft that changes the policy of the LoST Location
Profile registry from Standards Action to Specification Required (so
= NENA can add values):

https://www.ietf.org/= id/draft-ecrit-location-profile-registry-policy-00.txt

(The registry is at
https://www.= iana.org/assignments/lost-location-profiles/lost-location-profiles.xhtml<= /a>).

Comments are requested.

--Randall

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit
--=_MailMate_BE760295-339E-4006-9666-F7977215C973_=-- From nobody Fri Sep 25 16:09:49 2020 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB773A0B2A for ; Fri, 25 Sep 2020 16:09:46 -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, HTML_MESSAGE=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 g2X9O5FYKvPw for ; Fri, 25 Sep 2020 16:09:45 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id EE09E3A098D for ; Fri, 25 Sep 2020 16:09:44 -0700 (PDT) Received: from [169.254.186.78] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 25 Sep 2020 16:09:44 -0700 From: "Randall Gellens" To: "Ted Hardie" Cc: ecrit@ietf.org Date: Fri, 25 Sep 2020 16:09:43 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <15F97CDF-70CC-4612-B29E-80B43ED2DB35@coretechnologyconsulting.com> References: <795B3FC5-EDE8-49C2-96D9-EE785050DC2B@coretechnologyconsulting.com> <15F97CDF-70CC-4612-B29E-80B43ED2DB35@coretechnologyconsulting.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_27707D39-7AC7-475C-A75A-748BEA8B816C_=" Embedded-HTML: [{"HTML":[1090, 3677], "plain":[580, 2381], "uuid":"71CD5810-379B-4A2C-BF21-64068CA01C44"}] Archived-At: Subject: Re: [Ecrit] Changing the LoST Location Profile registry from Standards Action to Specification Required 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, 25 Sep 2020 23:09:47 -0000 --=_MailMate_27707D39-7AC7-475C-A75A-748BEA8B816C_= Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable Version -01 is available, with changes as suggested by Ted. Still only = 3 pages, so should be very easy to read. https://www.ietf.org/id/draft-ecrit-location-profile-registry-policy-01.t= xt Most significant change is in the IANA Considerations: The expert reviewer is designated by the responsible area director. The reviewer should verify that any proposed new value is specified by the IETF, NENA, = or a similar SDO, and meets a criteria of a clear need and unambiguous, interoperable definition. --Randall On 25 Sep 2020, at 14:14, Randall Gellens wrote: > Hi Ted, > > Thanks for your review, I appreciate it. If I understand, you're = > suggesting that in the IANA Considerations section it not name the = > expert reviewer (I thought I needed to), and to replace "The reviewer = > should use a criteria of a clear need and unambiguous definition for = > any new value" with "The reviewer should verify that any proposed = > value is specified by NENA or another SDO for emergency services, and = > meets a criteria of a clear need and unambiguous definition"? And also = > replace RFC 5226 with RFC 8126. > > --Randall > > On 25 Sep 2020, at 11:02, Ted Hardie wrote: > >> Hi Randy, >> >> Thanks for sharing the document. A couple of suggestions: a = >> citation to >> RFC 8126 would be useful, since "specification required" is defined = >> there. >> I'd also suggest that you change the IANA considerations in two ways. = >> At >> the moment, you name an expert reviewer, which is a bit out of the >> ordinary; I'd suggest removing that. Second, you currently have this = >> text >> in the introduction: >> >> This document changes the registry policy to Specification = >> Required, >> allowing other SDOs such as NENA to add values. >> >> "Specification required" is actually a good bit more open than this, = >> as it >> allows the expert to permit informal specifications (like >> internet-drafts). If this change is really specific to NENA and = >> similar >> emergency services bodies, I'd suggest moving this to the IANA >> considerations and making that an explicit instruction to the expert. = >> That >> would permit standards action plus those SDOs but would support the = >> expert >> continuing to limit the registry beyond those uses. >> >> best regards, >> >> Ted Hardie >> >> On Fri, Sep 25, 2020 at 9:16 AM Randall Gellens < >> rg+ietf@coretechnologyconsulting.com> wrote: >> >>> Hi ECRIT, >>> >>> I have a short draft that changes the policy of the LoST Location >>> Profile registry from Standards Action to Specification Required (so >>> NENA can add values): >>> >>> https://www.ietf.org/id/draft-ecrit-location-profile-registry-policy-= 00.txt >>> >>> (The registry is at >>> >>> https://www.iana.org/assignments/lost-location-profiles/lost-location= -profiles.xhtml >>> ). >>> >>> Comments are requested. >>> >>> --Randall >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=_MailMate_27707D39-7AC7-475C-A75A-748BEA8B816C_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Version -01 is available, with changes as suggested by Ted= =2E Still only 3 pages, so should be very easy to read.

https://www.ietf.o= rg/id/draft-ecrit-location-profile-registry-policy-01.txt

Most significant change is in the IANA Considerations:

The expert reviewer is
designated by the responsible area director. The reviewer should
verify that any proposed new value is specified by the IETF, NENA, or<= br> a similar SDO, and meets a criteria of a clear need and unambiguous, interoperable definition.

--Randall

On 25 Sep 2020, at 14:14, Randall Gellens wrote:

<= p dir=3D"auto">Hi Ted,

Thanks for your review, I appreciate it. If I understand= , you're suggesting that in the IANA Considerations section it not name t= he expert reviewer (I thought I needed to), and to replace "The reviewer = should use a criteria of a clear need and unambiguous definition for any = new value" with "The reviewer should verify that any proposed value is sp= ecified by NENA or another SDO for emergency services, and meets a criter= ia of a clear need and unambiguous definition"? And also replace RFC 5226= with RFC 8126.

--Randall

On 25 Sep 2020, at 11:02, Ted Hardie wrote:

Hi Randy,

Thanks for sharing= the document.=C2=A0=C2=A0 A couple of suggestions:=C2=A0 a citation to R= FC 8126 would be useful, since "specification required" is defi= ned there.=C2=A0 I'd also suggest that you change the IANA considerat= ions in two ways.=C2=A0 At the moment, you=C2=A0 name an expert reviewer,= which is a bit out of the ordinary; I'd suggest removing that.=C2=A0= Second, you currently have this text in the introduction:

= 
   This document changes the registry  policy to Specific=
ation Required, 
   allowing other SDOs such as NENA to add values.
"Specification required" is actually a good bit more= open than this, as it allows the expert to permit informal specification= s (like internet-drafts).=C2=A0 If this change is really specific to NENA= and similar emergency services bodies, I'd suggest moving this to th= e IANA considerations and making that an explicit instruction to the expe= rt.=C2=A0 That would permit standards action plus those SDOs but would su= pport the expert continuing to limit the registry beyond those uses.=C2=A0=

best regards,

Ted= Hardie

On Fri, Sep 25, 2020 at 9:16 AM Randall Gellens <rg+ietf@coretechn= ologyconsulting.com> wrote:
Hi ECRIT,

I have a short draft that changes the policy of the LoST Location
Profile registry from Standards Action to Specification Required (so
= NENA can add values):

https://www.ietf.org/= id/draft-ecrit-location-profile-registry-policy-00.txt

(The registry is at
https://www.= iana.org/assignments/lost-location-profiles/lost-location-profiles.xhtml<= /a>).

Comments are requested.

--Randall

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

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

--=_MailMate_27707D39-7AC7-475C-A75A-748BEA8B816C_=--