From nobody Fri Feb 14 14:22:32 2020 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9CB1200C1; Fri, 14 Feb 2020 14:22:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ecrit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ecrit@ietf.org Message-ID: <158171894673.16194.9824868628596288282@ietfa.amsl.com> Date: Fri, 14 Feb 2020 14:22:27 -0800 Archived-At: Subject: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-21.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: Fri, 14 Feb 2020 22:22:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies WG of the IETF. Title : Non-Interactive Emergency Calls Authors : Brian Rosen Henning Schulzrinne Hannes Tschofenig Randall Gellens Filename : draft-ietf-ecrit-data-only-ea-21.txt Pages : 23 Date : 2020-02-14 Abstract: RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' describes how devices use the Internet to place emergency calls and how Public Safety Answering Points (PSAPs) handle Internet multimedia emergency calls natively. The exchange of multimedia traffic for emergency services involves a Session Initiation Protocol (SIP) session establishment starting with a SIP INVITE that negotiates various parameters for that session. These calls involve a person, who uses the interactive media to communicate with the PSAP. In some cases, however, the transmission of application data is all that is needed, and no interactive media channel is established. Examples of such environments include alerts issued by a temperature sensor, burglar alarm, or chemical spill sensor. Often these alerts are conveyed as one-shot data transmissions. These type of interactions are called 'non-interactive emergency calls'. This document describes use of a SIP MESSAGE transaction containing a container for the data based on the Common Alerting Protocol (CAP). MESSAGE does not establish a session, which differentiates this type of emergency request from a SIP INVITE, which would. Any device that needs to initiate a request for emergency services where no interactive media channel will be established would use the mechanisms in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-21 https://datatracker.ietf.org/doc/html/draft-ietf-ecrit-data-only-ea-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-data-only-ea-21 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 Fri Feb 21 03:57:18 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 B5F4B120813 for ; Fri, 21 Feb 2020 03:57:16 -0800 (PST) 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 GRvf-a3A_e6D for ; Fri, 21 Feb 2020 03:57:15 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 304A1120800 for ; Fri, 21 Feb 2020 03:57:15 -0800 (PST) Received: from [10.8.1.10] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 21 Feb 2020 03:57:13 -0800 From: "Randall Gellens" To: ecrit@ietf.org Date: Fri, 21 Feb 2020 03:57:08 -0800 X-Mailer: MailMate (1.13.1r5671) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: [Ecrit] Registering the 'LoST-Validation' NAPTR Service Tag 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, 21 Feb 2020 11:57:17 -0000 Working in NENA, we've identified a need to register a new S-NAPTR service tag 'LoST-Validation'. Background: as some may recall, the key motivator for LoST was emergency services, primarily the ability to lookup a service URN for a location (i.e., map "URN:SERVICE:SOS" to a SIP URI for a PSAP for a specific location), and secondarily the ability to validate a civic location (i.e., validate that a civic address is unique, dispatchable, and meets the requirements for the area). LoST provides the ability to do both. NENA i3 (which defines NG9-1-1) makes extensive use of LoST. One thing NENA i3 does that was not originally contemplated when LoST was developed is to allow separation of the core mapping function of LoST from the validation function. NENA i3 allows (but does not require) these two services to be provided separately (with the motivation that mapping is a time-crucial service done during emergency call routing, while validation is performed as data is provisioned into entities and is not time-crucial, so a provider might potentially provision and operate these two services differently). LoST uses U-NAPTR Application Unique Strings rather than URIs to refer to other LoST servers. There is currently one U-NAPTR service tag for LoST ("LoST"). In order to be able to separate service mapping from location validation, a second service tag is needed. Otherwise an entity can't tell from an Application Unique String which server should be used for which service, and can't resolve an Application Unique String into a URI for a LoST server that should be used for location validation. We therefore propose to define "LoST-Validation" as a service tag. This will allow an entity to locate a LoST server identified as performing civic location validation, leaving "LoST" as the service tag for core service mapping. (Of course, a LoST server located using the 'LoST' service tag might offer both mapping and validation, but the ability to use 'LoST-Validation' in NAPTR records makes explicit which LoST servers are intended for validation.) The Service Tags registry rules that require an RFC to add a tag, so I have submitted a small RFC to do this: https://www.ietf.org/internet-drafts/draft-gellens-lost-validation-04.txt Comments, feedback, etc. are appreciated. --Randall From nobody Sun Feb 23 12:05:41 2020 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 487413A0DE7; Sun, 23 Feb 2020 12:05:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, allison.mankin@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <158248833928.1204.4586965683473226473.idtracker@ietfa.amsl.com> Date: Sun, 23 Feb 2020 12:05:39 -0800 Archived-At: Subject: [Ecrit] Barry Leiba's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2020 20:05:39 -0000 Barry Leiba has entered the following ballot position for draft-ietf-ecrit-data-only-ea-21: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this document. I have a very small ABNF issue I'd like to discuss, and which should be very easy to sort out one way or another: — Section 5.2 — ErrorValue = error-code *(SEMI error-params) … The ErrorValue contains a 3-digit error code indicating what was wrong with the alert in the request. This error code has a corresponding quoted error text string that is human readable. The text string is OPTIONAL, but RECOMMENDED for human readability, … Similar to how RFC 3261 specifies, there MUST NOT be more than one string per error code. Two things about this: 1. The ABNF makes the text string optional only by allowing zero or more of them (so zero is allowed). 2. The ABNF allows multiple text strings, but the text says that there MUST NOT be more than one. So, shouldn’t the ABNF be this (and if not, why not)?: NEW ErrorValue = error-code [SEMI error-params] END (Also, and not part of the DISCUSS, “Similar to how RFC 3261 specifies,” is not good English; maybe, “Similar to the specification in RFC 3261,” or “As similarly specified in RFC 3261,”.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some editorial comments: The Abstract strikes me as a bit long — certainly not ridiculously so, but longer than necessary for an abstract. Much of the information there, useful as it be, is stuff for an Introduction, not an Abstract. Clearly, this is entirely up to the working group, and this is just a minor comment. In case you find it useful, here’s what I would do with the Abstract for this: NEW 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. This document describes use of a SIP MESSAGE transaction that includes a container for the data based on the Common Alerting Protocol (CAP). That type of emergency request does not establish a session, distinguishing it from SIP INVITE, which does. Any device that needs to initiate a request for emergency services without an interactive media channel would use the mechanisms in this document. END — Section 1 — Examples of such environments includes sensors issuing alerts, or certain types of medical monitors. Nit: Examples “include”. And plural “examples” needs “and”, not “or”. These type of interactions Nit: These “types” Non-Interactive emergency calls are similar to regular emergency In the previous paragraph you didn’t capitalize “interactive”; usage should be consistent. calls in the sense that they require the emergency indications, emergency call routing functionality and may even have the same location requirements. The third item isn’t parallel to the first two. NEW calls in the sense that they require the emergency indications, they require emergency call routing functionality, and they may even have the same location requirements. END This document is concerned with citizen to authority "alerts", where the alert “citizen-to-authority”, as it’s a compound modifier. But shouldn’t it be “authority-to-citizen” anyway? (a URI is included in the message, which when dereferenced returns the CAP message). This sounds as if it’s the message that’s dereferenced. This reads better (and is also in active voice): NEW (the message includes a URI that, when dereferenced, returns the CAP message). END alert specific data beyond that available in the CAP message. Nit: “alert-specific” — Section 3 — 2. Establishing a third-party initiated emergency call Nit: “third-party-initiated” to determine the next hop proxy to route the alert message to. Nit: “next-hop proxy”x relationship between the originator and the receiver, e.g., a PSAP. A PSAP, for example, is likely to receive and accept alerts from The double “for example, PSAP” structure feels odd. I would just remove “, e.g., a PSAP” and let the “A PSAP, for example,…” take care of it. — Section 4.2 — given combination. Note that the element is optional and may not be present. A minor thing that you can ignore if you disagree with: I think “might not be present” is less likely to be confused with a BCP 14 “MAY” in this sentence construction. Arc- bands and ellipses SHOULD be converted to an equivalent polygon. 3D locations SHOULD be converted to their equivalent 2D forms. Can they really be made “equivalent”? Or do we really mean something like this (also correcting the number-agreement problem in the first sentence)?: NEW, maybe? Arc- bands and ellipses SHOULD be converted to polygons with similar coverage, and 3D locations SHOULD be converted to 2D forms with similar coverage. END — Section 5.2 — For example, a UA includes an alert in a MESSAGE to a PSAP. Nit: I would say, “For example, suppose a UA includes…” A SIP intermediary that requires the UA's alert message in order to properly process the transaction may also sends a 425 with an Nit: “may also send a 425” There MUST be no more than one AlertMsg-Error code in a SIP response. I find “MUST” with a negative statement to be awkward, especially when it’s easily avoided; it’s OK, of course, if you disagree. I suggest this: NEW There MUST NOT be more than one AlertMsg-Error code in a SIP response. END [RFC3262]; or, if that mechanism is not negotiated, it must be Nit: remove “it”. — Section 7 — The CAP message itself can be sent by-reference using this mechanism, as well as any or all of the Additional Data blocks that may contain sensor-specific data. This structure makes the antecedent to “as well as” ambiguous (it looks like it’s “this mechanism”, but it’s not). I suggest this (which also removes the stray hyphen from “by reference”): NEW The CAP message itself can be sent by reference using this mechanism, as can any or all of the Additional Data blocks that may contain sensor-specific data. END — Section 9 — Location specific threats are not unique to this document Nit: hyphenate “Location-specific” reason, it needs to be possible to refuse to accept alert messages from an unknown origin. Nit: “from unknown origins” Note that none of the security mechanism in this document protect Nit: “mechanisms” — Section 10.1 — Please use “media type”, not “MIME type” nor “MIME media type”. Please check the registration template in RFC 6838, Section 5.6, and align with it (there are just slight variations that will be easy to sort out). From nobody Sun Feb 23 14:43:22 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 A6C723A112D; Sun, 23 Feb 2020 14:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.276, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9snFuwJvhcg; Sun, 23 Feb 2020 14:43:05 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADB2F3A112B; Sun, 23 Feb 2020 14:43:02 -0800 (PST) Received: from [172.17.121.48] (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 01NMgvmu049699 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 23 Feb 2020 16:42:58 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1582497779; bh=z16Yyl9QfIqvgzX9dzMjXmQG4Qutsn9KScfeszn4hOs=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=I11UdHTIFBQqh2BNbRuW/UuNjLH2hhp2uBDrlM+KTjwn1nEWqn0jnmZV6ZxRWBxC2 fYlqguMMRC8SA4i4oJ4HCN4Yq4xvoQNOa/RR5pENj+vEoQHDjS77uvB3HllFKZkXLk EJT3rrOVJR2mGmYb/AbQwDDl5WMHZazBmGwxTtjI= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be [172.17.121.48] To: Barry Leiba , The IESG Cc: allison.mankin@gmail.com, ecrit-chairs@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-data-only-ea@ietf.org References: <158248833928.1204.4586965683473226473.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <9ab55a5d-8788-f407-1166-ea6e0b690b21@nostrum.com> Date: Sun, 23 Feb 2020 16:42:51 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <158248833928.1204.4586965683473226473.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Ecrit] Barry Leiba's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2020 22:43:08 -0000 On 2/23/2020 2:05 PM, Barry Leiba via Datatracker wrote: > — Section 5.2 — > > ErrorValue = error-code > *(SEMI error-params) > … > The ErrorValue contains a 3-digit error code indicating what was > wrong with the alert in the request. This error code has a > corresponding quoted error text string that is human readable. The > text string is OPTIONAL, but RECOMMENDED for human readability, > … > Similar to how RFC > 3261 specifies, there MUST NOT be more than one string per error > code. > > Two things about this: > > 1. The ABNF makes the text string optional only by allowing zero or more of > them (so zero is allowed). This is true. Is this a problem? A production like [*(SEMI error-params)] seems redundant. > 2. The ABNF allows multiple text strings, but the text says that there MUST NOT > be more than one. > > So, shouldn’t the ABNF be this (and if not, why not)?: > > NEW > ErrorValue = error-code [SEMI error-params] > END The production is like it is in the current document because "error-params" is not _just_ the error code text. It is defined as "error-code-text / generic-param", which is a common way to define SIP header fields so that future extensions fit the ABNF in a backwards-compatible way (by matching "generic-param"). If, for some reason, you wanted the ABNF to explicitly reflect the prose you're citing, it would end up looking like: Errorvalue = *(SEMI generic-param) [SEMI error-code-text] *(SEMI generic-param) But that's really unnecessarily prolix, and it doesn't even technically provide any enforcement, since "error-code-text" also matches "generic-param". What it comes down to is that this is one of the cases, common in SIP, where the decision was made to make the ABNF easy-to-read, and to provide enforcement of any semantic restrictions as part of the normative language rather than attempting to use syntax to do so. /a From nobody Sun Feb 23 16:48: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 14EB53A12EB; Sun, 23 Feb 2020 16:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 GAxNKsh_e0qL; Sun, 23 Feb 2020 16:48:15 -0800 (PST) Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) (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 C202D3A12EA; Sun, 23 Feb 2020 16:48:14 -0800 (PST) Received: by mail-il1-f195.google.com with SMTP id s85so6298651ill.11; Sun, 23 Feb 2020 16:48:14 -0800 (PST) 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=cN3PKBxVuaf9TjAGsrpaab6c8J/CIuuy3OnG+ATOE+E=; b=ipesNDVKf8ruWMlXsYJeFybX/e+WOCFqafFktXn7TTOwOqj4azw1+JftOTab9mSzJ5 GbQM03WyByl6f4MzZU8W3BbzT1ky5GkMXDecGtApHtEXQ9XTtlve6sFUeUI+PnxiCbJh HBntBGXkB3pb94742HTdp9H85V3nNkoLTdtrYTxH2qZmGh1AxtDA1Ay0/YOijO6syiZm /3DvQvELJEnRiMUN02qABCcU43fnvkiONkqGIsf//+pxNX4J7odNFzJHs0LCGhRUErtO D870kmsJNsjajuTBaWx5EvaxpgFNliwDh9DWANwqLSaQXcd2naQOvIDA7+Bm1tWwkB1E NW4g== X-Gm-Message-State: APjAAAVwazhWfT+2lGhY4REOqn++JNwiG9yh7dWiXusforV1EnyNxmlf bGQlEJSN99966X/wFO7nsCoUiacqG1ucIL82RHBMlUwt X-Google-Smtp-Source: APXvYqwtdk0kxJEmn5uqpEsHcaYNDEbO6ZbDU4TJBpQkh0mqG/W2cj/eE8U9VuzJ4o1fG7FHZX9x1QhYLFQ2Ixcw6VQ= X-Received: by 2002:a92:508:: with SMTP id q8mr54358448ile.187.1582505293820; Sun, 23 Feb 2020 16:48:13 -0800 (PST) MIME-Version: 1.0 References: <158248833928.1204.4586965683473226473.idtracker@ietfa.amsl.com> <9ab55a5d-8788-f407-1166-ea6e0b690b21@nostrum.com> In-Reply-To: <9ab55a5d-8788-f407-1166-ea6e0b690b21@nostrum.com> From: Barry Leiba Date: Sun, 23 Feb 2020 16:48:02 -0800 Message-ID: To: Adam Roach Cc: The IESG , Allison Mankin , ecrit-chairs@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-data-only-ea@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Ecrit] Barry Leiba's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 00:48:16 -0000 > > 1. The ABNF makes the text string optional only by allowing zero or more of > > them (so zero is allowed). > > This is true. Is this a problem? A production like [*(SEMI > error-params)] seems redundant. Not in itself; it was part of the overall comment, which is why point-by-point replies sometimes... miss the point (oof!). > The production is like it is in the current document because > "error-params" is not _just_ the error code text. It is defined as > "error-code-text / generic-param", which is a common way to define SIP > header fields so that future extensions fit the ABNF in a > backwards-compatible way (by matching "generic-param"). Ah, so here's the thing: I missed this line when I read it: / generic-param ; from RFC3261 ...and that's the key to why it's written as it is. Had I noticed it, I'd never have asked; thanks for pointing it out. I'm off to clear this point now. Barry From nobody Sun Feb 23 16:49:01 2020 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DB63A12EC; Sun, 23 Feb 2020 16:48:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, allison.mankin@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <158250533653.1160.12882300058392230264.idtracker@ietfa.amsl.com> Date: Sun, 23 Feb 2020 16:48:56 -0800 Archived-At: Subject: [Ecrit] Barry Leiba's No Objection on draft-ietf-ecrit-data-only-ea-21: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 00:48:57 -0000 Barry Leiba has entered the following ballot position for draft-ietf-ecrit-data-only-ea-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document. I have only a few editorial comments: The Abstract strikes me as a bit long — certainly not ridiculously so, but longer than necessary for an abstract. Much of the information there, useful as it be, is stuff for an Introduction, not an Abstract. Clearly, this is entirely up to the working group, and this is just a minor comment. In case you find it useful, here’s what I would do with the Abstract for this: NEW 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. This document describes use of a SIP MESSAGE transaction that includes a container for the data based on the Common Alerting Protocol (CAP). That type of emergency request does not establish a session, distinguishing it from SIP INVITE, which does. Any device that needs to initiate a request for emergency services without an interactive media channel would use the mechanisms in this document. END — Section 1 — Examples of such environments includes sensors issuing alerts, or certain types of medical monitors. Nit: Examples “include”. And plural “examples” needs “and”, not “or”. These type of interactions Nit: These “types” Non-Interactive emergency calls are similar to regular emergency In the previous paragraph you didn’t capitalize “interactive”; usage should be consistent. calls in the sense that they require the emergency indications, emergency call routing functionality and may even have the same location requirements. The third item isn’t parallel to the first two. NEW calls in the sense that they require the emergency indications, they require emergency call routing functionality, and they may even have the same location requirements. END This document is concerned with citizen to authority "alerts", where the alert “citizen-to-authority”, as it’s a compound modifier. But shouldn’t it be “authority-to-citizen” anyway? (a URI is included in the message, which when dereferenced returns the CAP message). This sounds as if it’s the message that’s dereferenced. This reads better (and is also in active voice): NEW (the message includes a URI that, when dereferenced, returns the CAP message). END alert specific data beyond that available in the CAP message. Nit: “alert-specific” — Section 3 — 2. Establishing a third-party initiated emergency call Nit: “third-party-initiated” to determine the next hop proxy to route the alert message to. Nit: “next-hop proxy”x relationship between the originator and the receiver, e.g., a PSAP. A PSAP, for example, is likely to receive and accept alerts from The double “for example, PSAP” structure feels odd. I would just remove “, e.g., a PSAP” and let the “A PSAP, for example,…” take care of it. — Section 4.2 — given combination. Note that the element is optional and may not be present. A minor thing that you can ignore if you disagree with: I think “might not be present” is less likely to be confused with a BCP 14 “MAY” in this sentence construction. Arc- bands and ellipses SHOULD be converted to an equivalent polygon. 3D locations SHOULD be converted to their equivalent 2D forms. Can they really be made “equivalent”? Or do we really mean something like this (also correcting the number-agreement problem in the first sentence)?: NEW, maybe? Arc- bands and ellipses SHOULD be converted to polygons with similar coverage, and 3D locations SHOULD be converted to 2D forms with similar coverage. END — Section 5.2 — For example, a UA includes an alert in a MESSAGE to a PSAP. Nit: I would say, “For example, suppose a UA includes…” A SIP intermediary that requires the UA's alert message in order to properly process the transaction may also sends a 425 with an Nit: “may also send a 425” There MUST be no more than one AlertMsg-Error code in a SIP response. I find “MUST” with a negative statement to be awkward, especially when it’s easily avoided; it’s OK, of course, if you disagree. I suggest this: NEW There MUST NOT be more than one AlertMsg-Error code in a SIP response. END [RFC3262]; or, if that mechanism is not negotiated, it must be Nit: remove “it”. — Section 7 — The CAP message itself can be sent by-reference using this mechanism, as well as any or all of the Additional Data blocks that may contain sensor-specific data. This structure makes the antecedent to “as well as” ambiguous (it looks like it’s “this mechanism”, but it’s not). I suggest this (which also removes the stray hyphen from “by reference”): NEW The CAP message itself can be sent by reference using this mechanism, as can any or all of the Additional Data blocks that may contain sensor-specific data. END — Section 9 — Location specific threats are not unique to this document Nit: hyphenate “Location-specific” reason, it needs to be possible to refuse to accept alert messages from an unknown origin. Nit: “from unknown origins” Note that none of the security mechanism in this document protect Nit: “mechanisms” — Section 10.1 — Please use “media type”, not “MIME type” nor “MIME media type”. Please check the registration template in RFC 6838, Section 5.6, and align with it (there are just slight variations that will be easy to sort out). From nobody Tue Feb 25 16:09:31 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 341ED3A091D for ; Tue, 25 Feb 2020 16:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 6I54fueBqSR4 for ; Tue, 25 Feb 2020 16:09:27 -0800 (PST) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 6716C3A091C for ; Tue, 25 Feb 2020 16:09:27 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id 13so1368059iou.1 for ; Tue, 25 Feb 2020 16:09:27 -0800 (PST) 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; bh=m5cLeZpgvmHsT8Chb1Zdhz4jaZ1GpqrIdHrub14WPTM=; b=AqE4SYR6YiPkwkjo0iJS8shNFv1E5Yz6wAaIW78CqAlBybx+S5oI5fJXJdR+fUDOu2 +hEZVBOrrgnO9O0L0LVnbc3W3hFQzvygxzCC6sszHoj/rHksqP/yEUpIKI8aqQDi6IlP Da2voIdSQkWIKFeidYjHHimL4p93PC1Rv8Sf8Jahf5mss+h/8b5r+k4a2fEBb4G+TfHN 1gSOEofr3XOLMoTKMy4GMHocoURs3kizAQN83H0oU/RHFOXStKsqmZ7RBp0jTBQ373ou 0ed0FWw+mkjItTYXpcYihWWba0qTocfBECopvZG+ih/OatVARQqciaiW7PSLa4HDLSrM zNqQ== 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; bh=m5cLeZpgvmHsT8Chb1Zdhz4jaZ1GpqrIdHrub14WPTM=; b=EOSskMs4Re9PEwRo6xXTBRzeBJSrHvWn520hoHDF7S3zwixzoj7b9zXWPP++Ii2/6i 0OZ0Q3k5h2XrHYo6dxO0ig1yMQg7tQeDlrAOCWKnlNakkarLOBF6/laEBomckR0AwEBf /eoMZhg3+o3iR3fF1PEx2ctVKuG/9Q6j9eGYTtVQDz0L6C+MN+g/TDg2wDBYyOZ0fj6d S6P5iJBr34qGauy92EbKwebJTP1m/qsi88Jvz9hFl38VFE2LO14LwYPL6BmnFounZ7SI 6MTXXLDheSt0i/PWTauFZXqenFSJXQz8huF/cOmDj1Qkk0OGwReLcm/PyUC3AIqRZceJ M4aQ== X-Gm-Message-State: APjAAAVlHqlIMIBUkGb8tARywIqTyGGUt57xFu/wT/yqCa/ZmM5NWhkz TLvlS8cqR/n0YBMWnM3Z5HkJlx+WL5GRXF7jEf3+vQ== X-Google-Smtp-Source: APXvYqx1KQgGxbtgJPTvtKznXEbZfEcpMBt9Bl5qcB8o3YUo0rFob8x54uDGZ+2LY6GTxBJY2B/MiyWuNBr5iUB+tqg= X-Received: by 2002:a02:a388:: with SMTP id y8mr1182612jak.70.1582675766299; Tue, 25 Feb 2020 16:09:26 -0800 (PST) MIME-Version: 1.0 References: <158267385016.11018.7094919989285181688.idtracker@ietfa.amsl.com> In-Reply-To: <158267385016.11018.7094919989285181688.idtracker@ietfa.amsl.com> From: Barry Leiba Date: Tue, 25 Feb 2020 16:09:14 -0800 Message-ID: To: ecrit@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Ecrit] Fwd: Last Call: (The LoST-Validation S-NAPTR Application Service Tag) to Informational RFC 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, 26 Feb 2020 00:09:29 -0000 I wanted to alert this group explicitly to the subject last call. If anyone has comments about it, please make them as specified below, to , rather than discussing it on this list. Thanks, Barry, ART AD ---------- Forwarded message --------- From: The IESG Date: Tue, Feb 25, 2020 at 3:37 PM Subject: Last Call: (The LoST-Validation S-NAPTR Application Service Tag) to Informational RFC To: IETF-Announce Cc: , Ben Campbell , The IESG has received a request from an individual submitter to consider the following document: - 'The LoST-Validation S-NAPTR Application Service Tag' as Informational RFC 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 2020-03-31. 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 adds the LoST-Validation service tag to the S-NAPTR Application Service Tag IANA registry. This tag is used by clients of the Location-to-Service Translation Protocol (LoST). The file can be obtained via https://datatracker.ietf.org/doc/draft-gellens-lost-validation/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-gellens-lost-validation/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Feb 27 19:44:28 2020 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C873A0D22; Thu, 27 Feb 2020 19:44:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Mohit Sethi via Datatracker To: Cc: ecrit@ietf.org, draft-ietf-ecrit-data-only-ea.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158286145629.12729.7571746436683650433@ietfa.amsl.com> Reply-To: Mohit Sethi Date: Thu, 27 Feb 2020 19:44:16 -0800 Archived-At: Subject: [Ecrit] Genart telechat review of draft-ietf-ecrit-data-only-ea-21 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 03:44:17 -0000 Reviewer: Mohit Sethi 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-ecrit-data-only-ea-21 Reviewer: Mohit Sethi Review Date: 2020-02-27 IETF LC End Date: 2019-09-02 IESG Telechat date: 2020-03-05 Summary: My comments on version -18 were addressed. The document is ready. From nobody Fri Feb 28 10:23:54 2020 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 352AD3A1BCE; Fri, 28 Feb 2020 10:23:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, Allison Mankin , draft-ietf-ecrit-data-only-ea@ietf.org, allison.mankin@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <158291422008.22449.8600928959018481644@ietfa.amsl.com> Date: Fri, 28 Feb 2020 10:23:40 -0800 Archived-At: Subject: [Ecrit] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-ecrit-data-only-ea-21=3A_=28with_COMMENT=29?= X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 18:23:41 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-ecrit-data-only-ea-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One question: Should non-inactive SIP MESSAGEs be rated-limited somehow or it that already specified in the SIP spec (sorry don't know that by heart ;-)? If so a pointer would probably be good. Or maybe another thing to add to section 7 (or a subsection or an own section) or alternatively to the security considerations section I guess. One small comment/nit: Sec 5.2: "AlertMsg-Error values sent in provisional responses must be sent using the mechanism defined in [RFC3262]; or, if that mechanism is not negotiated, it must be repeated in the final response to the transaction." Maybe two times MUST? From nobody Fri Feb 28 11:18:48 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 43F6E3A1A0F for ; Fri, 28 Feb 2020 11:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcwpql4pKBbt for ; Fri, 28 Feb 2020 11:18:42 -0800 (PST) Received: from mail-yw1-xc2e.google.com (mail-yw1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) (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 C2E763A1A0A for ; Fri, 28 Feb 2020 11:18:41 -0800 (PST) Received: by mail-yw1-xc2e.google.com with SMTP id o186so103871ywc.1 for ; Fri, 28 Feb 2020 11:18:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8wWOKq1W7edL60VuAQfCkhoEEwO8ySGmdcImRSyoKFw=; b=Rtud5yc7/QkwrLNxBUrQkLMQ5HZxZXbJizIJGQWzoNK7wTvaKSUDK8opnoX97VW4UA 9lh2i7v3EuxDFc6CA83BHwGueS5fb3ocv26IX0FtFUPX4+yGiKujzCDdS9V6QwPf0y7Y M9h3M2OQpcUhb9XtsmFHCYql3Cw+2byKu9tcJC436JDEYJfqlbIA0J6t7RfplAoQKFOK LSsxASss/PXauvPEFKX1qu5sVyEPd6+DE2zF2P51xbZ4KASay79ijmyQ3JijmIhOedzp 59F6pDbD1F3glbPY+DRKmxMBVBPuMZaFpeVOnGbaKBeW5xKavpU6I8uo+2x6OX+jHzcJ vUZA== 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=8wWOKq1W7edL60VuAQfCkhoEEwO8ySGmdcImRSyoKFw=; b=KSHF9ke08UVQs6gOf1rD0yKoM16gup13QE2kWBSXTE4rdZdZCEyouO7ghjhOitj6Yb dxuckldUI7E1kqMSAizx6pU03n67VaGa7IPhokmiqneceSHZtjAF3j/HK+J0h9fuuiVJ oUsjPr7wUQiA+Pfe+3iSLCWq0zWe8ncq3rA1z/29AQBgCPzoX2m7CCI9Q5iSQKcnl27w XEtOmDJpB+a/jsTCtqMw6XSYPUZOvZEwphensbqQt6GM60vA3ekP6HhG4d1Qr1z87ee2 dr2JPmN/19+BHYgq2FKMcRyUcsAGX0/iPq/rq9deGRPlgYWmBl6QooeKesjmVf1r3qJ5 c6vg== X-Gm-Message-State: APjAAAU1cIflYjLdBJzgQw+MXKiCLHI7jGPYlCWShpvQs70JIYyPfrjQ b9Hph58LEpoFaekFO2tTL9ZFwA== X-Google-Smtp-Source: APXvYqyEQIApNUeWifSxOnC7y5PZqVKXcC77fePG/txAROQLKHgm7hUxR/O+H0UbAPOcd4GmL48s2Q== X-Received: by 2002:a81:610b:: with SMTP id v11mr5666991ywb.488.1582917520887; Fri, 28 Feb 2020 11:18:40 -0800 (PST) Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id a12sm1184659ywm.0.2020.02.28.11.18.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Feb 2020 11:18:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Brian Rosen In-Reply-To: <158291422008.22449.8600928959018481644@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:18:32 -0500 Cc: The IESG , draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ECRIT , Allison Mankin Content-Transfer-Encoding: quoted-printable Message-Id: References: <158291422008.22449.8600928959018481644@ietfa.amsl.com> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Ecrit] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-ecrit-data-only-ea-21=3A_=28with_COMMENT=29?= X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 19:18:46 -0000 Thanks for your comments. There is no rate limit for MESSAGE. I will add text that discusses it. = As a practical matter, a person is involved in every message, so the = rate has to be very slow. While the systems that deal with these = messages have to be hardened against DoS of all forms, I agree the text = should discuss the issue and at least offer some guidance. I will also add text to Security Considerations, since DoS is a = consideration. Yes, both of those musts should be MUSTs. I will fix that. Brian > On Feb 28, 2020, at 1:23 PM, Mirja K=C3=BChlewind via Datatracker = wrote: >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-ecrit-data-only-ea-21: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > One question: Should non-inactive SIP MESSAGEs be rated-limited = somehow or it > that already specified in the SIP spec (sorry don't know that by heart = ;-)? If > so a pointer would probably be good. Or maybe another thing to add to = section 7 > (or a subsection or an own section) or alternatively to the security > considerations section I guess. >=20 > One small comment/nit: > Sec 5.2: > "AlertMsg-Error values sent in > provisional responses must be sent using the mechanism defined in > [RFC3262]; or, if that mechanism is not negotiated, it must be > repeated in the final response to the transaction." > Maybe two times MUST? >=20 >=20 >=20