Re: [Ecrit] Barry Leiba's No Objection on draft-ietf-ecrit-data-only-ea-21: (with COMMENT)
Brian Rosen <br@brianrosen.net> Mon, 09 March 2020 21:05 UTC
Return-Path: <br@brianrosen.net>
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 9FA9C3A1742 for <ecrit@ietfa.amsl.com>; Mon, 9 Mar 2020 14:05:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEvcOfZWDDkg for <ecrit@ietfa.amsl.com>; Mon, 9 Mar 2020 14:05:42 -0700 (PDT)
Received: from mail-yw1-xc44.google.com (mail-yw1-xc44.google.com [IPv6:2607:f8b0:4864:20::c44]) (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 4D87A3A1717 for <ecrit@ietf.org>; Mon, 9 Mar 2020 14:05:42 -0700 (PDT)
Received: by mail-yw1-xc44.google.com with SMTP id t141so11583063ywc.11 for <ecrit@ietf.org>; Mon, 09 Mar 2020 14:05:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Pl75FEg+I+xnUg7RVyjOwvqtGHj+rNalEvaETTDnQGw=; b=xlGdiGVRw7R3MwpkvWDoLvWXzd6+FeZGl/sJt2MaKS9X8g69hs2RlnrLV0gFXPOCcl oNlKL7OoNDI5o5ahIvdjdibrbYb+a4zt6UGiB+whxDKjfTk5/+JblnkbIgf/yYM22ggI mPiG6fb4Ahujjt9Zek7sG4P/0RVVCzxKVnK1TeV5ie73vDNzyeILAzzG4m0EruVRq+lZ ppCJyUqTfHoOhrOTrET56i5gzMtHqxmAR6sC51a8TsFowmfojya3W5i9dr9/ZCPdaLRP eIETNXPmm907UvMC4QgB5dVH0zBjFru/g0sKLrJjxHBA6JtTS+GjiiI1MYm7Y9BGEeoI VvbA==
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=Pl75FEg+I+xnUg7RVyjOwvqtGHj+rNalEvaETTDnQGw=; b=jitNT4sMqJtMA+5Wwwt92eJsrggpPYPkciAde8MFjor47DnnWVCHsVnAbTwkf5W83I HXmGSX2nzWvziUudE4Vd3BuG8Jv1M5AA3iGkjTTP8gZDHu0azEhBrPpoY84AkaMseFja 1lO67I+q5cgRbAkRmYzqcVoyeMIbEDo8C7UvLb7v1vhIkEXA2C5tYMEhbJTIYrkKn94t d64ySsEgF1c9W6ZHd4ov7w9osJADUf8ql5r8dvNHsN56qucxBJzWQ/ctgQfiHkn0h/Vl nnG9B5TH5W2vSnu7JMNFT2js8Isn9zljXRut9rP2RDRr0ZLNQDDWALBxzD5XtGuqKDMv jc9g==
X-Gm-Message-State: ANhLgQ2oQKPz4G45PRdIngh16JSiNoJsK6hxjm78rSJGDH8NeE0aoGws KMlatS1l8EwharVJkNi83BiWLg==
X-Google-Smtp-Source: ADFU+vuTkfxdTSBN79HOoplxwvBHW5wPrIr+mhrFRbnOigoMKRuMKphwNUm5Cs1whBCx9DSPSszRGQ==
X-Received: by 2002:a0d:c487:: with SMTP id g129mr19861097ywd.366.1583787941243; Mon, 09 Mar 2020 14:05:41 -0700 (PDT)
Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id u84sm3515609ywb.26.2020.03.09.14.05.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2020 14:05:39 -0700 (PDT)
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 <br@brianrosen.net>
In-Reply-To: <158250533653.1160.12882300058392230264.idtracker@ietfa.amsl.com>
Date: Mon, 09 Mar 2020 17:05:38 -0400
Cc: The IESG <iesg@ietf.org>, draft-ietf-ecrit-data-only-ea@ietf.org, ecrit-chairs@ietf.org, ecrit@ietf.org, Allison Mankin <allison.mankin@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DBD81B36-5D9D-4681-8D3C-ECC4D61A8019@brianrosen.net>
References: <158250533653.1160.12882300058392230264.idtracker@ietfa.amsl.com>
To: Barry Leiba <barryleiba@computer.org>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/clmJsf0Jx3MREQ-18J1yTBmBtxc>
Subject: Re: [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
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: Mon, 09 Mar 2020 21:05:45 -0000
-22 addresses your comments, I hope. https://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-22 Brian > On Feb 23, 2020, at 7:48 PM, Barry Leiba via Datatracker <noreply@ietf.org> wrote: > > 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 <sender, expires, incidents> combination. Note that the > <expires> 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). > > >
- [Ecrit] Barry Leiba's No Objection on draft-ietf-… Barry Leiba via Datatracker
- Re: [Ecrit] Barry Leiba's No Objection on draft-i… Brian Rosen