IETF Logo Mail Archive

Re: [Rum] I-D Action: draft-ietf-rum-rue-03.txt

James Hamlin <james.hamlin@purple.us> Mon, 21 September 2020 09:04 UTC

Return-Path: <james.hamlin@purple.us>
X-Original-To: rum@ietfa.amsl.com
Delivered-To: rum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7759B3A0AF6 for <rum@ietfa.amsl.com>; Mon, 21 Sep 2020 02:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.341
X-Spam-Level:
X-Spam-Status: No, score=-0.341 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 9Nu-L2TDxG6L for <rum@ietfa.amsl.com>; Mon, 21 Sep 2020 02:04:37 -0700 (PDT)
Received: from outbound-ip1a.ess.barracuda.com (outbound-ip1a.ess.barracuda.com [209.222.82.168]) (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 608993A0AF1 for <rum@ietf.org>; Mon, 21 Sep 2020 02:04:37 -0700 (PDT)
Received: from smtp.purple.us (smtp01.purple.us.91.17.208.in-addr.arpa [208.17.91.143]) by mx3.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 21 Sep 2020 09:04:34 +0000
Received: from 1-WP-401-EXCH.purplenetwork.net (10.0.10.143) by 1-wp-401-exch.purplenetwork.net (10.0.10.143) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 21 Sep 2020 02:04:33 -0700
Received: from 1-WP-401-EXCH.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb]) by 1-wp-401-exch.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb%13]) with mapi id 15.00.1263.000; Mon, 21 Sep 2020 02:04:33 -0700
From: James Hamlin <james.hamlin@purple.us>
To: "rum@ietf.org" <rum@ietf.org>
Thread-Topic: [Rum] I-D Action: draft-ietf-rum-rue-03.txt
Thread-Index: AQHWj/Gl4E/+9/1icEKqjKU/sGCygg==
Date: Mon, 21 Sep 2020 09:04:32 +0000
Message-ID: <1600679072074.473@purple.us>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.0.10.15]
Content-Type: multipart/alternative; boundary="_000_1600679072074473purpleus_"
MIME-Version: 1.0
X-BESS-ID: 1600679073-893004-18708-162632-1
X-BESS-VER: 2019.1_20200918.2058
X-BESS-Apparent-Source-IP: 208.17.91.143
X-BESS-Outbound-Spam-Score: 0.20
X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.227041 [from cloudscan20-197.us-east-2b.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_BESS_OUTBOUND META: BESS Outbound 0.20 BSF_SC0_SA953 META: Custom Rule BSF_SC0_SA953 0.00 HTML_IMAGE_ONLY_20 BODY: HTML: images with 1600-2000 bytes of words
X-BESS-Outbound-Spam-Status: SCORE=0.20 using global scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND, BSF_SC0_SA953, HTML_IMAGE_ONLY_20
X-BESS-BRTS-Status: 1
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/N6jdoJ1SVzcuj9Qe1p9bAzC1vUA>
Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-03.txt
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2020 09:04:38 -0000

Brian


Thanks for the new draft.


I think the final sentence in section 5.2.5. "Emergency Calls" is out of scope, as it tries to define the interface between the VRS provider and the PSAP. From the rest of the text, the purpose of the data exchange between RUE and VRS provider is already clear; the final sentence could be dropped without detracting from the description of the RUM interface. I propose dropping the text: "Providers MUST implement Data Provider and Service Information blocks as the call is forwarded to the PSAP.".


Best Regards


James


[X][X]

[X]James Hamlin
Contractor
Purple, a Division of ZP Better Together, LLC
purplevrs.com

The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.

v2.23.0 | Report a Bug | By Email