From nobody Mon Oct 3 10:51:16 2016 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 0F236129417; Mon, 3 Oct 2016 10:51:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147551707405.29632.7658924910525484199.idtracker@ietfa.amsl.com> Date: Mon, 03 Oct 2016 10:51:14 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-14.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 17:51:14 -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 of the IETF. Title : Next-Generation Pan-European eCall Authors : Randall Gellens Hannes Tschofenig Filename : draft-ietf-ecrit-ecall-14.txt Pages : 44 Date : 2016-10-03 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of the Pan European in- vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles, providing real-time communications and an integrated set of related data. This document also registers MIME Content Types and an Emergency Call Additional Data Blocks for the eCall vehicle data and metadata/ control data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-ecall-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-14 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 Mon Oct 3 10:51:35 2016 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 08996129434; Mon, 3 Oct 2016 10:51:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147551708402.29688.13395676043049144252.idtracker@ietfa.amsl.com> Date: Mon, 03 Oct 2016 10:51:24 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-13.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 17:51:24 -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 of the IETF. Title : Next-Generation Vehicle-Initiated Emergency Calls Authors : Randall Gellens Brian Rosen Hannes Tschofenig Filename : draft-ietf-ecrit-car-crash-13.txt Pages : 42 Date : 2016-10-03 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data. This document also registers a MIME Content Type and Emergency Call Additional Data Block for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash). An external specification for the data format, contents, and structure are referenced in this document. This document reuses the technical aspects of next-generation pan- European eCall (a mandated and standardized system for emergency calls by in-vehicle systems within Europe and other regions). However, this document specifies a different set of vehicle (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This document is an extension of the eCall document, with the primary differences being that this document makes the MSD data set optional and VEDS mandatory, and adds attribute values to the eCall metadata/control object to permit greater functionality. This document registers a new INFO package (identical to that registered for eCall but with the addition of the VEDS MIME type). This document also describes legacy (circuit- switched) ACN systems and their migration to next-generation emergency calling, to provide background information and context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-13 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 Mon Oct 3 10:53:55 2016 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 87E0C129453 for ; Mon, 3 Oct 2016 10:53:53 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-2.996] 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 YPOAgVKIHJA8 for ; Mon, 3 Oct 2016 10:53:52 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1577E129434; Mon, 3 Oct 2016 10:53:52 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 3 Oct 2016 10:53:51 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <147460051915.22446.3905020998297020767.idtracker@ietfa.amsl.com> <147460071860.22446.2297178978097588073.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Mon, 3 Oct 2016 10:53:49 -0700 To: ecrit@ietf.org From: Randall Gellens Cc: ecrit@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-14 & draft-ietf-ecrit-car-crash-13 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 17:53:53 -0000 Hi everyone, An issue arose with the MIME media type registrations. After discussion and consultation on the meda-types list and with individuals, to address it, I added text to the IANA Considerations section of eCall to formalize the "EmergencyCallData" subtype tree. I want to thank Ned Freed for his help. At 8:23 PM -0700 9/25/16, Randall Gellens wrote: > I updated car-crash to -12, to add a sentence to the Terminology > section that clarifies that "IVS" can mean either an IVS or TSP > when discussing signaling. > > > At 8:11 PM -0700 9/24/16, Randall Gellens wrote: > >> Hi ECRIT, >> >> The versions draft-ietf-ecrit-ecall-13 & >> draft-ietf-ecrit-car-crash-11 address all comments. >> >> --Randy >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > Never ask two questions in a business letter. The reply will > discuss the one you are least interested in and say nothing about > the other. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- It has been observed that one's nose is never so happy as when it is thrust into the affairs of another, from which some physiologists have drawn the inference that the nose is devoid of the sense of smell. --Ambrose Bierce, "The Devil's Dictionary" From nobody Tue Oct 4 06:56:21 2016 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 A739312987D for ; Tue, 4 Oct 2016 06:56:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147558937668.12927.869924618506788235.idtracker@ietfa.amsl.com> Date: Tue, 04 Oct 2016 06:56:16 -0700 From: IETF Secretariat Archived-At: Subject: [Ecrit] Milestones changed for ecrit WG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 13:56:20 -0000 Changed milestone "Submit 'Validation of Locations Around a Planned Change' to the IESG for consideration as a Standards Track RFC", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/ecrit/charter/ From nobody Tue Oct 4 09:03:45 2016 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 62E7C1293E1 for ; Tue, 4 Oct 2016 09:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 nn6jUcSWtsYy for ; Tue, 4 Oct 2016 09:03:39 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 21B871293DC for ; Tue, 4 Oct 2016 09:03:39 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id d132so38376587oib.2 for ; Tue, 04 Oct 2016 09:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZIsn2NN84Wkj97f8gY1+OGqZwd+To8Zb23XmQUTCoFk=; b=NAhSh5TqmzwBotmKG/zJosZlYorbMAT03oW2WU9rCV6QU9V9mhAjXYwwzsOLL9EMBg 19TY1/vhkxmadFsOE1oppDCK3LYZU23vABMRq/bvNYZqryCq5ncbWG4zxSDwt3Gy2tv/ GAq8Slq4ydNHIo5IyZ2uMQj22yskclL+v7wdFayuiKezz/VxyAq0P6fnSL0mbda2g2RG GnWmYHOWdE/eG5RrZFd6U2MAE/L/fjco2kh1Njn07rfH3ELOxoHQbaKrdBYUB8eGi6Pk 7F9V388nDZGuhYy/gf3Y7+sOHRLEyyb4KG5636d5agepiOZYal7SGCvqYeKTfHRC8Mii xG1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZIsn2NN84Wkj97f8gY1+OGqZwd+To8Zb23XmQUTCoFk=; b=ljhlw6ICKPkcmA8Q8MDknTwiW+rjHpWcjrlSFnbHJPfs+Z5u+OxHcai1hTAaGmiH/N z66Sr0niy5XY1kUc9TmHNX8HcVqShz3BHkkwncmnC14/4qKTEl6EAVfZf+VvK12FOV8n 5TBJYg7aojtK2ZdwkdEuzh1wmvCLBDRODgpnivu/rWYiw2Th7F4ozlV2kp/1XnkMvOQk gHUyQ8nHoFnVAi+R62JDEWjN8DXRUUhAf5lUWl/Gzhrmspe8NPsP7VU5gOz63P4XKVY4 blsgfCMfSg8ju6tTM68Aa4vsa4sRIxFsdQcamJCr8+8geaWwCtNOokfmvpjVGgx3RZ6r 7+FQ== X-Gm-Message-State: AA6/9RmIIcHlyF2rALzkxeVVDmF+LGTdP7wUk3/eKl0PjVdhg08MjkKLkZIuS7jfIaNTNwpeGfP2nsFp7wyzzQ== X-Received: by 10.202.173.202 with SMTP id w193mr3586926oie.51.1475597018426; Tue, 04 Oct 2016 09:03:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.193.136 with HTTP; Tue, 4 Oct 2016 09:03:37 -0700 (PDT) Received: by 10.202.193.136 with HTTP; Tue, 4 Oct 2016 09:03:37 -0700 (PDT) In-Reply-To: References: <147460051915.22446.3905020998297020767.idtracker@ietfa.amsl.com> <147460071860.22446.2297178978097588073.idtracker@ietfa.amsl.com> From: Az Mankin Date: Tue, 4 Oct 2016 12:03:37 -0400 Message-ID: To: Randy Gellens Content-Type: multipart/alternative; boundary=001a113cf5d61d7426053e0c3459 Archived-At: Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-14 & draft-ietf-ecrit-car-crash-13 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 16:03:43 -0000 --001a113cf5d61d7426053e0c3459 Content-Type: text/plain; charset=UTF-8 Thank you Randy (and Ned). Now that that is resolved, we will go to WGLC. On Oct 3, 2016 10:53, "Randall Gellens" wrote: > Hi everyone, > > An issue arose with the MIME media type registrations. After discussion > and consultation on the meda-types list and with individuals, to address > it, I added text to the IANA Considerations section of eCall to formalize > the "EmergencyCallData" subtype tree. I want to thank Ned Freed for his > help. > > > At 8:23 PM -0700 9/25/16, Randall Gellens wrote: > > I updated car-crash to -12, to add a sentence to the Terminology section >> that clarifies that "IVS" can mean either an IVS or TSP when discussing >> signaling. >> >> >> At 8:11 PM -0700 9/24/16, Randall Gellens wrote: >> >> Hi ECRIT, >>> >>> The versions draft-ietf-ecrit-ecall-13 & draft-ietf-ecrit-car-crash-11 >>> address all comments. >>> >>> --Randy >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> Never ask two questions in a business letter. The reply will >> discuss the one you are least interested in and say nothing about >> the other. >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > It has been observed that one's nose is never so happy as when > it is thrust into the affairs of another, from which some > physiologists have drawn the inference that the nose is devoid > of the sense of smell. > --Ambrose Bierce, "The Devil's Dictionary" > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > --001a113cf5d61d7426053e0c3459 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thank you Randy (and Ned).

Now that that is resolved, we will go to WGLC.


On Oct 3, 2016 10= :53, "Randall Gellens" <rg+ietf@randy.pensive.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Hi everyone,

An issue arose with the MIME media type registrations.=C2=A0 After discussi= on and consultation on the meda-types list and with individuals, to address= it, I added text to the IANA Considerations section of eCall to formalize = the "EmergencyCallData" subtype tree. I want to thank Ned Freed f= or his help.


At 8:23 PM -0700 9/25/16, Randall Gellens wrote:

=C2=A0I updated car-crash to -12, to add a sentence to the Terminology sect= ion that clarifies that "IVS" can mean either an IVS or TSP when = discussing signaling.


=C2=A0At 8:11 PM -0700 9/24/16, Randall Gellens wrote:

=C2=A0 Hi ECRIT,

=C2=A0 The versions draft-ietf-ecrit-ecall-13 & draft-ietf-ecrit-car-cr= ash-11 address all comments.

=C2=A0 --Randy

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


=C2=A0--
=C2=A0Randall Gellens
=C2=A0Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I= speak for myself only
=C2=A0-------------- Randomly selected tag: ---------------
=C2=A0Never ask two questions in a business letter.=C2=A0 The reply will =C2=A0discuss the one you are least interested in and say nothing about
=C2=A0the other.

=C2=A0_______________________________________________
=C2=A0Ecrit mailing list
=C2=A0Ecrit@ietf.org
=C2=A0https://www.ietf.org/mailman/listinfo/ecrit


--
Randall Gellens
Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak= for myself only
-------------- Randomly selected tag: ---------------
It has been observed that one's nose is never so happy as when
it is thrust into the affairs of another, from which some
physiologists have drawn the inference that the nose is devoid
of the sense of smell.
=C2=A0 =C2=A0 =C2=A0 =C2=A0--Ambrose Bierce, "The Devil's Dictiona= ry"

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
--001a113cf5d61d7426053e0c3459-- From nobody Tue Oct 4 09:16:29 2016 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 9C56212961E; Tue, 4 Oct 2016 09:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 zefk0-Cbx14a; Tue, 4 Oct 2016 09:16:27 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 782251295AB; Tue, 4 Oct 2016 09:16:26 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id y190so163846663vkd.3; Tue, 04 Oct 2016 09:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tbtJdps8+JB0XtW6wv/2bZmqLWJHhHJL4sEWrj385c4=; b=UPf7/HOlvTXLZaEidtxPqTf6azLpO2Vz1qDvuOICaz2EBNUavI/l4fNysPbNqLiWSy D1ZguaYDNxRU3nOoZe9jbYgozDEot7RXpeJ/Lhmi6JAy/cvme9CJHxH73En3YGHXFf6U 5jQSlmZPwUSLWHT6JEb7CI+0JFt96l3iI7KlbzueMRR1LjQb+PA8b19hBESVm8qC0kre sv4g/r8EPalbJ+xW+sPdJ3R3CK+oWRv4d7azc5XzlPElAx7K977RC4/iAt2FuqyQA16o i+ZApq0cOhRGsE2hPZzfhk9Eq0FWjnmxKNmS/iamx+bdnIAWY3HXUbpKZLWzVw+I1x2z RUeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tbtJdps8+JB0XtW6wv/2bZmqLWJHhHJL4sEWrj385c4=; b=iPUclF4i6Z7ztT6NuKlLoK+cmqh9QRhP7lVAh5vR13uj8VHvTiW9I5tviei3QBscZN sS1517wkND3P2cFdz5cGfiEknbzFWY0LLaIi3+oPAylF7VynFFnHEdvSZ9zS73FeuLyZ CfgZ8P/x33mhC4lx9cPt++spFdQOBsLHVqkqbj5TJnK5ChjgQPaYPSVYTLdMA4T9fnys ERi9I2g5xaiOTqsWy+QG4akSe0G0j/KVWrsVIA7cMfV/mbCZTM5yOm7PBlA9A21KL4P8 xiQpRy/yVnjgYSTURIwH0EMWI5DPAVh4sKQa/lGNiUyPhKT4T+KPax5jARYfTXBmVXIF Ok3Q== X-Gm-Message-State: AA6/9RkBfbcWiPGaIHbApX76WpneCIu5tYMVFOmY4r6kYSaF1/cIkc9G/DskLUya7pTOGErNtIN/1dlNmWG0XA== X-Received: by 10.31.150.201 with SMTP id y192mr2513727vkd.74.1475597785323; Tue, 04 Oct 2016 09:16:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.34.84 with HTTP; Tue, 4 Oct 2016 09:16:24 -0700 (PDT) Received: by 10.159.34.84 with HTTP; Tue, 4 Oct 2016 09:16:24 -0700 (PDT) In-Reply-To: References: From: Allison Mankin Date: Tue, 4 Oct 2016 09:16:24 -0700 Message-ID: To: ecrit@ietf.org Content-Type: multipart/alternative; boundary=001a1141f50ed36aa7053e0c6184 Archived-At: Cc: ecrit-chairs@ietf.org Subject: [Ecrit] WG Last Call for draft-ietf-ecrit-car-crash-13 -- ends 10/18 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 16:16:28 -0000 --001a1141f50ed36aa7053e0c6184 Content-Type: text/plain; charset=UTF-8 This begins WGLC for draft-ecrit-car-crash-13. It will be a standard 2 week last call ending October 18. Send statements of support and any final comments (I understand we had sort of a WGLC earlier) to the list. ---------- Forwarded message ---------- From: "IETF Secretariat" Date: Oct 4, 2016 09:06 Subject: IETF WG state changed for draft-ietf-ecrit-car-crash To: , , < allison.mankin@gmail.com> Cc: The IETF WG state of draft-ietf-ecrit-car-crash has been changed to "In WG Last Call" from "WG Document" by Allison Mankin: https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ --001a1141f50ed36aa7053e0c6184 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

This begins WGLC for draft-ecrit-car-crash-13.

It will be a standard 2 week last call ending October 18.

Send statements of support and any final comments (I underst= and we had sort of a WGLC earlier) to the list.

---------- Forwarded message ----------
From:= "IETF Secretariat" <ietf-secretariat-reply@ietf.org>
Date: Oct 4, 2016 09:0= 6
Subject: IETF WG state changed for draft-ietf-ecrit-car-crash
To: = <ecrit-chairs@ietf.org>,= <draft-ietf-ecr= it-car-crash@ietf.org>, <allison.mankin@gmail.com>
Cc:

<= blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex">
The IETF WG state of draft-ietf-ecrit-car-crash has been changed to "I= n
WG Last Call" from "WG Document" by Allison Mankin:

https://datatracker.ietf.org/doc/dr= aft-ietf-ecrit-car-crash/


--001a1141f50ed36aa7053e0c6184-- From nobody Tue Oct 4 09:20:32 2016 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 65D19129589; Tue, 4 Oct 2016 09:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 esK7Us-QENXz; Tue, 4 Oct 2016 09:20:29 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 1870C1293D8; Tue, 4 Oct 2016 09:20:29 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id y190so163968276vkd.3; Tue, 04 Oct 2016 09:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3oRrkqI4gZgtyC4XPCyDGnPBQbASjFn03s/Noq7apsM=; b=rm4rjUI+UTV4Z2V2Y9Y6JbfcSLyuRYS5xZOE+JitC+ICki+s38WuvCn4IoUzJtwyUF 5AeMoGvN6pm9VtEWtAskMlVFWQNds12q+siHlrS1ydxALbDFYjR1PQDqx9zu5hWGuL8E cOx88GijPxFF7yX0Ijp7Kn80pvWZnJ1HuwAoCgqL931YRv+IewxUyCLIGp341Gj9t9D/ aRiSVxGLiPJgIAltOC/yeBXvr8pfTn+eX+7883a/3q0EepNywXNFNqbVRyScBn3vIHuR DKFr53zXy6Rj0MEv4XXVS3n2GvxEt7lUC3Ae8ao2jbHYFPBkUglHKPmLIMDzIjSV+LRT wVeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3oRrkqI4gZgtyC4XPCyDGnPBQbASjFn03s/Noq7apsM=; b=YtN1r9I9kHWpVsbWyENSfDJz5EC9CgXrn+8V6uHCzdbsTtE3ldsdxxGA7TGeQNqJX+ Sn95R377m3MGhICbWRLErCQ1uO4ZTolYafuncfD3QVJtB6/F//GzP+3eARIjtgid5m8e /3ge9b0lDye2hMMDlBzZmahgPrzeNXxBx+S+rv68O62UR5azPb3zcrhZn0MINUPTT9qT kz5FsK7TGTTOuVbD+6jQx26QlV1EqxY5BzRblYeKrzRlWDjggbpogME3C6REygO7XpiH xgM8KEU2I5TdoAWjkHCkE0yztoQ7XkgAOM7bFlJzDpPWdN8cgM6KDTo5OS4lBWv1j2cR Ir5Q== X-Gm-Message-State: AA6/9RmbVlhpyJQp+eakXJOTBK9X/dz6Lrt6yo0wdN44JiL6wjWkudLCZrZsmK90BEJ/velUX4vnxgYxiEZtKg== X-Received: by 10.31.205.71 with SMTP id d68mr2580069vkg.6.1475598028210; Tue, 04 Oct 2016 09:20:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.34.84 with HTTP; Tue, 4 Oct 2016 09:20:27 -0700 (PDT) Received: by 10.159.34.84 with HTTP; Tue, 4 Oct 2016 09:20:27 -0700 (PDT) In-Reply-To: References: From: Allison Mankin Date: Tue, 4 Oct 2016 09:20:27 -0700 Message-ID: To: ecrit@ietf.org Content-Type: multipart/alternative; boundary=001a114dddc44daea7053e0c7005 Archived-At: Cc: ecrit-chairs@ietf.org Subject: [Ecrit] WGLC for draft-ietf-ecrit-ecall-14 -- ends 10/18 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 16:20:30 -0000 --001a114dddc44daea7053e0c7005 Content-Type: text/plain; charset=UTF-8 This begins WGLC for draft-ietf-ecrit-ecall-14. It will be a standard 2 week last call ending October 18. Send statements of support and any final comments (I understand we had sort of a WGLC earlier) to the list. --001a114dddc44daea7053e0c7005 Content-Type: text/html; charset=UTF-8

This begins WGLC for draft-ietf-ecrit-ecall-14.

It will be a standard 2 week last call ending October 18.

Send statements of support and any final comments (I understand we had sort of a WGLC earlier) to the list.

--001a114dddc44daea7053e0c7005-- From nobody Tue Oct 4 09:40:39 2016 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 342DF120726; Tue, 4 Oct 2016 09:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 qlV7IghiCChW; Tue, 4 Oct 2016 09:40:35 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 241911293DF; Tue, 4 Oct 2016 09:40:34 -0700 (PDT) X-AuditID: c1b4fb2d-1dbff700000009f7-f5-57f3db802ff5 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id AE.3C.02551.08BD3F75; Tue, 4 Oct 2016 18:40:33 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0319.002; Tue, 4 Oct 2016 18:40:32 +0200 From: Christer Holmberg To: Allison Mankin , "ecrit@ietf.org" Thread-Topic: [Ecrit] WGLC for draft-ietf-ecrit-ecall-14 -- ends 10/18 Thread-Index: AQHSHls8jlVvOQzyf0a9/zQLrTc5ZqCYfpYg Date: Tue, 4 Oct 2016 16:40:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BD19142@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BD19142ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM2J7oG7j7c/hBm1blCyud39jspjU9ZTN onHRU1YHZo+ds+6yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK+PL1p1sBXscKnbu3s/cwHjFrouR k0NCwETi9MeJ7F2MXBxCAusZJQ6emsMG4SxilJj1u4eli5GDg03AQqL7nzZIg4hAkETT0zVM IDazgLHEvKMr2EBsYQFXiUlT+xkhatwkfk15zwjSKiJgJLHqixtImEVARWLDv4MsIDavgK9E 9601YLaQwD1GiaUPzUFsToFAiSNz74GNZxQQk/h+CmaVuMStJ/OZIG4WkFiy5zwzhC0q8fLx P1YIW0lixfZLjBD1+RKzH75lg9glKHFy5hOWCYwis5CMmoWkbBaSsllAVzMLaEqs36UPUaIo MaX7ITuErSHROmcuO7L4Akb2VYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiB0XVwy2/dHYyr XzseYhTgYFTi4X2w9XO4EGtiWXFl7iFGCQ5mJRFeq2tAId6UxMqq1KL8+KLSnNTiQ4zSHCxK 4rxmK++HCwmkJ5akZqemFqQWwWSZODilGhibO4O4Z2XdEfjtLP1v1wlVsV8r/FO191jvd/S0 3yf68e0KgSPvVO9Fv67fIMlvcHNJ3s3oV5ZMi57uE9y1fa+S7xW+xMiS2S8zo80sZn/iPWnI ceT43+vlYb7N/WVSAS23C8y9chc//PYzwfMgq0py/N2+/P33lC/qN5b2dp7buTjx8jNpniYl luKMREMt5qLiRABBto+4qgIAAA== Archived-At: Cc: "ecrit-chairs@ietf.org" Subject: Re: [Ecrit] WGLC for draft-ietf-ecrit-ecall-14 -- ends 10/18 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 16:40:37 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BD19142ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgbWF5IHByb3ZpZGUgbW9yZSBjb21tZW50cyBsYXRlciwgYnV0IHdlIHN0aWxsIGhh dmUgdGhlIGlzc3VlIHdpdGggdXNpbmcgQ29udGVudC1JRCBhcyBhIFNJUCBoZWFkZXIgZmllbGQu DQoNCldlIGRpZCBzdWJtaXQgYSBkcmFmdCB0byBTSVBDT1JFIGluIG9yZGVyIHRvIGZpeCB0aGF0 LCBidXQgaXQgaGFzbuKAmXQgY2F1Z2h0IGFueSB0cmFjdGlvbi4gUGVyaGFwcyB0aGUgY2hhaXJz IGNvdWxkIHRhbGsgd2l0aCB0aGUgU0lQQ09SRSBjaGFpcnM/DQoNCkkgYXNzdW1lIHRoaXMgaXNz dWUgYWxzbyBhcHBsaWVzIHRvIGRyYWZ0LWNhci1jcmFzaC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KRnJvbTogRWNyaXQgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgQWxsaXNvbiBNYW5raW4NClNlbnQ6IDA0IE9jdG9iZXIgMjAxNiAxOToyMA0KVG86IGVj cml0QGlldGYub3JnDQpDYzogZWNyaXQtY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBbRWNyaXRd IFdHTEMgZm9yIGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTQgLS0gZW5kcyAxMC8xOA0KDQoNClRo aXMgYmVnaW5zIFdHTEMgZm9yIGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTQuDQoNCkl0IHdpbGwg YmUgYSBzdGFuZGFyZCAyIHdlZWsgbGFzdCBjYWxsIGVuZGluZyBPY3RvYmVyIDE4Lg0KDQpTZW5k IHN0YXRlbWVudHMgb2Ygc3VwcG9ydCBhbmQgYW55IGZpbmFsIGNvbW1lbnRzIChJIHVuZGVyc3Rh bmQgd2UgaGFkIHNvcnQgb2YgYSBXR0xDIGVhcmxpZXIpIHRvIHRoZSBsaXN0Lg0K --_000_7594FB04B1934943A5C02806D1A2204B4BD19142ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGlu az0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPkkgbWF5IHByb3ZpZGUgbW9yZSBjb21tZW50cyBsYXRlciwgYnV0IHdlIHN0aWxs IGhhdmUgdGhlIGlzc3VlIHdpdGggdXNpbmcgQ29udGVudC1JRCBhcyBhIFNJUCBoZWFkZXIgZmll bGQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5XZSBkaWQgc3VibWl0 IGEgZHJhZnQgdG8gU0lQQ09SRSBpbiBvcmRlciB0byBmaXggdGhhdCwgYnV0IGl0IGhhc27igJl0 IGNhdWdodCBhbnkgdHJhY3Rpb24uIFBlcmhhcHMgdGhlIGNoYWlycyBjb3VsZCB0YWxrIHdpdGgg dGhlIFNJUENPUkUNCiBjaGFpcnM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5JIGFzc3VtZSB0aGlzIGlzc3VlIGFsc28gYXBwbGllcyB0byBkcmFmdC1jYXItY3Jhc2gu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBFY3JpdCBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFsbGlzb24gTWFua2luPGJyPg0KPGI+U2VudDo8L2I+IDA0 IE9jdG9iZXIgMjAxNiAxOToyMDxicj4NCjxiPlRvOjwvYj4gZWNyaXRAaWV0Zi5vcmc8YnI+DQo8 Yj5DYzo8L2I+IGVjcml0LWNoYWlyc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRWNy aXRdIFdHTEMgZm9yIGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTQgLS0gZW5kcyAxMC8xODxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHA+VGhpcyBiZWdpbnMgV0dMQyBmb3IgZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xNC48 bzpwPjwvbzpwPjwvcD4NCjxwPkl0IHdpbGwgYmUgYSBzdGFuZGFyZCAyIHdlZWsgbGFzdCBjYWxs IGVuZGluZyBPY3RvYmVyIDE4LjxvOnA+PC9vOnA+PC9wPg0KPHA+U2VuZCBzdGF0ZW1lbnRzIG9m IHN1cHBvcnQgYW5kIGFueSBmaW5hbCBjb21tZW50cyAoSSB1bmRlcnN0YW5kIHdlIGhhZCBzb3J0 IG9mIGEgV0dMQyBlYXJsaWVyKSB0byB0aGUgbGlzdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4BD19142ESESSMB209erics_-- From nobody Wed Oct 5 11:15:37 2016 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 D29971297CA for ; Wed, 5 Oct 2016 11:15:35 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 Y9xsl6lyoRj7 for ; Wed, 5 Oct 2016 11:15:33 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4A06312943D for ; Wed, 5 Oct 2016 11:15:33 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 5 Oct 2016 11:15:32 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <147460051915.22446.3905020998297020767.idtracker@ietfa.amsl.com> <147460071860.22446.2297178978097588073.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Wed, 5 Oct 2016 11:15:29 -0700 To: Az Mankin From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-14 & draft-ietf-ecrit-car-crash-13 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 18:15:36 -0000 Hi Allison, In our phone call a few weeks ago, I understood you were going to issue WG LC for these two docs right away, in parallel with resolution of the MIME issue, and run LC for only one week because of the amount of time the group (including Ivo) have considered the docs to have been in LC already. I'm curious what changed that made you delay the LC until today, and run for two weeks? --Randy At 12:03 PM -0400 10/4/16, Az Mankin wrote: > Thank you Randy (and Ned). > > Now that that is resolved, we will go to WGLC. > > > On Oct 3, 2016 10:53, "Randall Gellens" > <rg+ietf@randy.pensive.org> > wrote: > > Hi everyone, > > An issue arose with the MIME media type registrations. After > discussion and consultation on the meda-types list and with > individuals, to address it, I added text to the IANA Considerations > section of eCall to formalize the "EmergencyCallData" subtype tree. > I want to thank Ned Freed for his help. > > > At 8:23 PM -0700 9/25/16, Randall Gellens wrote: > > I updated car-crash to -12, to add a sentence to the Terminology > section that clarifies that "IVS" can mean either an IVS or TSP > when discussing signaling. > > > At 8:11 PM -0700 9/24/16, Randall Gellens wrote: > > Hi ECRIT, > > The versions draft-ietf-ecrit-ecall-13 & > draft-ietf-ecrit-car-crash-11 address all comments. > > --Randy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > Never ask two questions in a business letter. The reply will > discuss the one you are least interested in and say nothing about > the other. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > It has been observed that one's nose is never so happy as when > it is thrust into the affairs of another, from which some > physiologists have drawn the inference that the nose is devoid > of the sense of smell. > --Ambrose Bierce, "The Devil's Dictionary" > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The Pledge of Allegiance says `liberty and justice for all'. Which part of `all' don't you understand? --Rep. Pat Schroeder (D) Colorado From nobody Thu Oct 6 04:22:14 2016 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 2BDA5129600 for ; Thu, 6 Oct 2016 04:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 uNSvq0W9nKnp for ; Thu, 6 Oct 2016 04:22:11 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 4937212950F for ; Thu, 6 Oct 2016 04:22:11 -0700 (PDT) X-AuditID: c1b4fb25-5405a9800000793b-51-57f633e1a3fb Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id F0.35.31035.1E336F75; Thu, 6 Oct 2016 13:22:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0319.002; Thu, 6 Oct 2016 13:21:11 +0200 From: Christer Holmberg To: Randall Gellens , Az Mankin Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-14 & draft-ietf-ecrit-car-crash-13 Thread-Index: AQHSH8O94qA7xmROrEunhnbuWGSQng== Date: Thu, 6 Oct 2016 11:21:10 +0000 Message-ID: References: <147460051915.22446.3905020998297020767.idtracker@ietfa.amsl.com> <147460071860.22446.2297178978097588073.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <864E4FA756CB5A40B70479089E97EB80@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7me5D42/hBst/aVssnbqTyaJx0VNW i+/PuxgdmD12zrrL7rFkyU8mj613HrMEMEdx2aSk5mSWpRbp2yVwZfzZ1cZU8FGu4tOc7WwN jE8kuhg5OSQETCS+d59m6mLk4hASWM8o0bb6PytIQkhgEaPE++WMXYwcHGwCFhLd/7RBwiIC gRK9098wgdjMAqoS5xofs4DYwgIBEk+XQsRBav5cXQVl60mcX3sNbCSLgIrEsX9L2UFsXgFr iXnXbzBD7P3BJPH99mOwBk6ggx697WAGsRkFxCS+n1oDtUxc4taT+UwQRwtILNlznhnCFpV4 +fgf2AJRoGXfv86GiitJ/NhwiQWiV0/ixtQpbBC2tcTkk/egbG2JZQtfM0McJChxcuYTlgmM 4rOQrJuFpH0WkvZZSNpnIWlfwMi6ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwBg9u+a26 g/HyG8dDjAIcjEo8vAvsv4YLsSaWFVfmHmKU4GBWEuGtNfgWLsSbklhZlVqUH19UmpNafIhR moNFSZzXbOX9cCGB9MSS1OzU1ILUIpgsEwenVAMj58QIrbIN4hIFX55syFDjPHn1WVv2PiNp 1TLug4r6BjvjdjpP9/m0S/xzgm/9JNbSftmeEh6Vd08u/ShdGSfsop29Jf5LImP5YbHaqLCg dMkDhvzRuzrkmh7X/w383Sj2/d5t/t1svRobZJmuvxE5kO/cW3z846WEG8m8p01ObBCwvcLI Jq7EUpyRaKjFXFScCACOvCYivQIAAA== Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-14 & draft-ietf-ecrit-car-crash-13 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 11:22:13 -0000 Hi, Again, we need to decide on what to do regarding using Content-ID as a SIP header field. If we decide to not care about the fact the header field hasn=B9t been defined for SIP, we should at least say that in the spec. The best thing would obviously be to get the SIPCORE draft adopted, as this is not an ECRIT-specific issue. Regards, Christer On 05/10/16 21:15, "Ecrit on behalf of Randall Gellens" wrote: >Hi Allison, > >In our phone call a few weeks ago, I understood you were going to >issue WG LC for these two docs right away, in parallel with >resolution of the MIME issue, and run LC for only one week because of >the amount of time the group (including Ivo) have considered the docs >to have been in LC already. I'm curious what changed that made you >delay the LC until today, and run for two weeks? > >--Randy > >At 12:03 PM -0400 10/4/16, Az Mankin wrote: > >> Thank you Randy (and Ned). >> >> Now that that is resolved, we will go to WGLC. >> >> >> On Oct 3, 2016 10:53, "Randall Gellens" >> <rg+ietf@randy.pensive.org> >> wrote: >> >> Hi everyone, >> >> An issue arose with the MIME media type registrations. After >> discussion and consultation on the meda-types list and with >> individuals, to address it, I added text to the IANA Considerations >> section of eCall to formalize the "EmergencyCallData" subtype tree. >> I want to thank Ned Freed for his help. >> >> >> At 8:23 PM -0700 9/25/16, Randall Gellens wrote: >> >> I updated car-crash to -12, to add a sentence to the Terminology >> section that clarifies that "IVS" can mean either an IVS or TSP >> when discussing signaling. >> >> >> At 8:11 PM -0700 9/24/16, Randall Gellens wrote: >> >> Hi ECRIT, >> >> The versions draft-ietf-ecrit-ecall-13 & >> draft-ietf-ecrit-car-crash-11 address all comments. >> >> --Randy >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >>=20 >>=20 >>https://www.ietf.org/mailman >>/listinfo/ecrit >> >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself >>only >> -------------- Randomly selected tag: --------------- >> Never ask two questions in a business letter. The reply will >> discuss the one you are least interested in and say nothing about >> the other. >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >>=20 >>=20 >>https://www.ietf.org/mailman >>/listinfo/ecrit >> >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> It has been observed that one's nose is never so happy as when >> it is thrust into the affairs of another, from which some >> physiologists have drawn the inference that the nose is devoid >> of the sense of smell. >> --Ambrose Bierce, "The Devil's Dictionary" >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >>=20 >>=20 >>https://www.ietf.org/mailman >>/listinfo/ecrit > > >--=20 >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly selected tag: --------------- >The Pledge of Allegiance says `liberty and justice for all'. Which part >of `all' don't you understand? --Rep. Pat Schroeder (D) Colorado > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From nobody Thu Oct 6 05:59:27 2016 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 42F49129647 for ; Thu, 6 Oct 2016 05:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 medF9XbJL8eW for ; Thu, 6 Oct 2016 05:59:24 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 A7548129644 for ; Thu, 6 Oct 2016 05:59:23 -0700 (PDT) X-AuditID: c1b4fb3a-e95069800000099a-9b-57f64aa92eb3 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id 05.20.02458.9AA46F75; Thu, 6 Oct 2016 14:59:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0319.002; Thu, 6 Oct 2016 14:58:42 +0200 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: Content-ID: Way forward without SIPCORE impact Thread-Index: AQHSH9FdW92vWNIey0OuUNcxPMNfjQ== Date: Thu, 6 Oct 2016 12:58:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D41C26AC10977christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7h+4qr2/hBpMcLBoXPWV1YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfG3nfXmAsWC1W0blzN3MC4iL+LkZNDQsBE4sO5ncxdjFwcQgLr GSWWrt7JBJIQEljEKHGpMbaLkYODTcBCovufNkhYREBVYsOZlYwgtrCAucSfbzeYIeI2ElO/ 3WEGKRcR0JPY/yMAJMwioCLR+OIrO4jNK2At8bH7K1gro4CYxPdTa8A2MQuIS9x6Mp8J4hwB iSV7zjND2KISLx//YwWxRYFGfv86GyquKLHzbDszRG+CxNe3E9kg5gtKnJz5hGUCo9AsJGNn ISmbhaQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPgXo5gGxriX2LY5CVLGDkWMUoWpxaXJybbmSk l1qUmVxcnJ+nl5dasokRGCMHt/y22sF48LnjIUYBDkYlHt4F9l/DhVgTy4orcw8xSnAwK4nw /nP/Fi7Em5JYWZValB9fVJqTWnyIUZqDRUmc12zl/XAhgfTEktTs1NSC1CKYLBMHp1QDY6Gy feyMm4f4XukKrTSQSHqbe1RzqzuP/oLgo2ks21Mv7FV1XKJ7scl//uNF+ZKSsZvvRfQHuSdW Zy1u7FlZ/qumY27TFKZjO5Y53bUJMFnDstWlcXuKwP5JJ6V3qposmXhjT9+TbfuDWlvZSzzz JDiWTdtnIbePecu6I1/9/9xxFLuXLXLWRYmlOCPRUIu5qDgRAB2qdZONAgAA Archived-At: Subject: [Ecrit] Content-ID: Way forward without SIPCORE impact X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 12:59:25 -0000 --_000_D41C26AC10977christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One way to solve the Content-ID issue would be to ALWAYS use a multipart MI= ME, even if we only carry one body part. See example in section 12.2.2.3 of= RFC 6086. Another advantage would be that we would always the same Content-Dispositio= n header field value for the MSD/control body parts. Currently the value is= dependent on whether there are other body parts in the message or not, whi= ch is a little strange. So, the multipart/MIME would have C-D:info-package = and the MSD/control body part would have C-D:by-reference. Comments? Regards, Christer (It may still be a good idea to define usage of Content-ID for SIP, but the= n the ECRIT specs would not be held up due to that work) --_000_D41C26AC10977christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

One way to solve the Content-ID issue would be to ALWAYS use a multipa= rt MIME, even if we only carry one body part. See example in section 12.2.2= .3 of RFC 6086.

Another advantage would be that we would always the same Content-Dispo= sition header field value for the MSD/control body parts. Currently the val= ue is dependent on whether there are other body parts in the message or not= , which is a little strange. So, the multipart/MIME would have C-D:info-package and the MSD/control body pa= rt would have C-D:by-reference.

Comments?

Regards,

Christer

(It may still be a good idea to define usage of Content-ID for SIP, bu= t then the ECRIT specs would not be held up due to that work)
--_000_D41C26AC10977christerholmbergericssoncom_-- From nobody Thu Oct 6 08:40:23 2016 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 6CE701296D8 for ; Thu, 6 Oct 2016 08:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 ZMgml7KIK274 for ; Thu, 6 Oct 2016 08:40:21 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 642611296CE for ; Thu, 6 Oct 2016 08:40:20 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-10v.sys.comcast.net with SMTP id sAm0bsgpmRingsAmRbPyG6; Thu, 06 Oct 2016 15:40:19 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-02v.sys.comcast.net with SMTP id sAmRbRdO7ervfsAmRbOHO6; Thu, 06 Oct 2016 15:40:19 +0000 To: ecrit@ietf.org References: From: Paul Kyzivat Message-ID: Date: Thu, 6 Oct 2016 11:40:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfH9/YJEJFaEyceMXgwm1h6PWIvIhYCN/TMFW/28z9NBFsMA4K1C01oglueShbdauTpQt1ICNcp2e+70dBL/qhRFXSnhYdISKQhqZtKHsWJSONws+vOBz sy1Re81O9NrqMa77vKLH6YKK+2TghTY/DsOZIyGHC8q1/17iIVrlIB7C Archived-At: Subject: Re: [Ecrit] Content-ID: Way forward without SIPCORE impact X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 15:40:22 -0000 On 10/6/16 8:58 AM, Christer Holmberg wrote: > Hi, > > One way to solve the Content-ID issue would be to ALWAYS use a multipart > MIME, even if we only carry one body part. See example in section > 12.2.2.3 of RFC 6086. This is certainly a possibility Thanks, Paul > Another advantage would be that we would always the same > Content-Disposition header field value for the MSD/control body parts. > Currently the value is dependent on whether there are other body parts > in the message or not, which is a little strange. So, the multipart/MIME > would have C-D:info-package and the MSD/control body part would have > C-D:by-reference. > > Comments? > > Regards, > > Christer > > (It may still be a good idea to define usage of Content-ID for SIP, but > then the ECRIT specs would not be held up due to that work) > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From nobody Thu Oct 6 14:06:33 2016 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 0608512979A for ; Thu, 6 Oct 2016 14:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digitaldatatech.onmicrosoft.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 mVNyTgHsYcfy for ; Thu, 6 Oct 2016 14:06:28 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0074.outbound.protection.outlook.com [104.47.40.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE6E12978A for ; Thu, 6 Oct 2016 14:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digitaldatatech.onmicrosoft.com; s=selector1-ddti-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0Le39VFJOnC1coohXgTDLGVlNgwu8linkIPOUXcPuZ4=; b=qFeslIFhaYUyY1K/2z4XzChr4Yn8jUNgG9PMc9iMhArYrqzk5Go58+jXxjXSvsjvVL2xEw/dUNH628JS9Sx7ZszG1QZdJV2WwBCOvwkU5LEWRuocOMauqfNBoixZQIVl4J4kyYlTb9nyensvh1QCDuyZQ8lrOOqfIY/JqVIwhow= Received: from MWHPR17MB1071.namprd17.prod.outlook.com (10.173.122.9) by MWHPR17MB1071.namprd17.prod.outlook.com (10.173.122.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Thu, 6 Oct 2016 21:06:20 +0000 Received: from MWHPR17MB1071.namprd17.prod.outlook.com ([10.173.122.9]) by MWHPR17MB1071.namprd17.prod.outlook.com ([10.173.122.9]) with mapi id 15.01.0649.024; Thu, 6 Oct 2016 21:06:20 +0000 From: Dan Banks To: "ecrit@ietf.org" Thread-Topic: draft-ietf-ecrit-similar-location-03 feedback Thread-Index: AdIdrtnm6THJi+eWToW54tTsv9BaDQ== Date: Thu, 6 Oct 2016 21:06:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=DBanks@ddti.net; x-originating-ip: [4.53.197.18] x-ms-office365-filtering-correlation-id: a898903e-3e26-4cba-5038-08d3ee2c9f5b x-microsoft-exchange-diagnostics: 1; MWHPR17MB1071; 6:x0KMSpQKsGDy6qeYbJ41Sx51bCi1cVfedoAJc1//kFqgrRrTIDNoTl7fKrxWMUckC1JEjcwQMNQ2j+XUlwA5ILTiZGNPCYjsrjHGnbV64KHka5xniWMwi4tnY6CaXL3qjbgz7CxhpdrMmQjLvETHMLaXpaS+KC6eDFusAAndB/vREV/Ds6dFJax0Y/WsAngWU1Zoa1QO0Ge4vvLV7bKRPvB7CTswZF4Vs6SKL9EBnroJc5VPU9HqdrtcFHiQXrUZb1bcW2z7PJndJeMOQ01Eumw4uiudWGVleCR5vUrjOwA4tl6+0pXWTvLOdYAnEO7b; 5:WEc/JzDEJCQ4vAmgFqlQsYhUT4jtm3k2GhNd7p0bX9RTvMBUBM3HZ1xdx+hAkjqJrKRjaX1rKf203OswORLBBwbef4JTrbhTFE3EtecCosBd4LRuQJXJJGzt+PKU+9+ZEA8+9FAnQlN83YGYkoh6cQa1R/b5Y0Y8Npe0qQieThY=; 24:vZT/1VeJNXilLnZnQkZoVnqopuz6DZI6JKTkm91IrQNSZPPueUd4ykvkGSx/QBc5PBsDzOA/QqYi+WPs7PtsiY9Bd8+p5fx+sdTdB/XQcjY=; 7:8vG++nZf5NRk7yxRkV6iUgGHJlmswa8v0zjByanYW106+61IDeFJ8/a3sWlw7TrZd+m9A9byahPThG8GrJUiNCYuXlKCNi3AE6xueLIjrw2UTEmytI5YizE9r3L5NvZ3oKSchisO1rKRtuAPKU4fxK6IGvcrH6FoRXqf2mr5sFLNVcRR6LkrMv/Bic7v+fPiuVoc+5qAgst9aimBOdno5JQrwgWvO4bHsjCuJvC0Rgp+WROJztkGB/y8sagUlc5LQWFtfWCFID7vT6W9JpbvKAqV8cRbnO546Lv0wx+k+mzkDI6BZpRFWUqJF3iQfy9jxmxVNA+PG/UF7DtS0dAi1g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR17MB1071; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(131327999870524)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:MWHPR17MB1071; BCL:0; PCL:0; RULEID:; SRVR:MWHPR17MB1071; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(199003)(92566002)(3660700001)(9686002)(76576001)(16236675004)(790700001)(6916009)(97736004)(5002640100001)(80792005)(189998001)(19580395003)(33656002)(5640700001)(8936002)(5630700001)(2501003)(10400500002)(102836003)(3846002)(2900100001)(68736007)(6116002)(15975445007)(3280700002)(19617315012)(19625215002)(586003)(86362001)(2906002)(7696004)(74316002)(66066001)(105586002)(77096005)(230783001)(110136003)(50986999)(54356999)(4326007)(99286002)(7736002)(229853001)(81156014)(81166006)(101416001)(1730700003)(106356001)(87936001)(122556002)(7846002)(19300405004)(8676002)(2351001)(7906003)(11100500001)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR17MB1071; H:MWHPR17MB1071.namprd17.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ddti.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR17MB107171FFC603A9DA683B5DBFA7C70MWHPR17MB1071namp_" MIME-Version: 1.0 X-OriginatorOrg: ddti.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2016 21:06:20.3320 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4c0f48ba-5f29-44b1-b29c-1aff8251101b X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR17MB1071 Archived-At: Cc: "Rosen, Brian \(Brian.Rosen@neustar.biz\)" Subject: [Ecrit] draft-ietf-ecrit-similar-location-03 feedback X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 21:06:31 -0000 --_000_MWHPR17MB107171FFC603A9DA683B5DBFA7C70MWHPR17MB1071namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been working on an implementation of the similar location mechanism = described by draft-ietf-ecrit-similar-location-03, and have some feedback: 1) For completeLocation, the actual element name in the schema is "completedlo= cation", with a 'd' and lowercase 'l'. It appears this should be "complete= Location". There is also a use of "completedLocation" on page 5 that shoul= d be changed. Also, there will only be a single completeLocation returned. ## ## completeLocation ## div { completeLocation =3D element completedlocation { locationInformation }+ } Should be: ## ## completeLocation ## div { completeLocation =3D element completeLocation { locationInformation } } 2) An element "returnedLocationResponse" is defined by the schema, but not dis= cussed in the text or illustrated in the examples: div { returnedLocationResponse =3D element returnedLocationResponse { completeLocation, similarLocation, extensionPoint } } Perhaps we need a better way state that completeLocation or similarLocation= elements can be placed at the existing extension point within the LoST loc= ationValidation element. 3) It is desirable to have away for a client to specifically request RLI, inst= ead of it being included any time that validation is performed. Responses = with multiple similar locations can quickly become large compared to respon= ses without RLI, and may also incur additional processing cost at the serve= r. This could be wasteful if automated validation is being performed or if= the RLI is otherwise not understood or discarded. I suggest an attribute = be added to the findService request (perhaps rli:returnLocation) with defin= ed values of { "none" | "similar" | "complete" | "any" } to indicate which= return location types the client is interested in. Further, I suggest tha= t the server be restricted to including only RLI types in the response that= are requested, and that omitting the attribute from the request is equival= ent to rli:returnLocation=3D"none". 4) The text and schema state that the similarLocation and completeLocation ele= ments include the "profile" attribute, but this is not shown in the example= s. RFC5222 makes the profile attribute optional in location chunks. On th= e server side, this means that any location chunks without a profile attrib= ute need to be further analyzed to see if they can be recognized, which is = an unnecessary complication. On the client side, the response pertains to = one particular location in the request (indicated by ), so th= e profile could be assumed from that, but I would much rather have it be ex= plicit. I suggest we make the profile attribute mandatory where it is used within t= his extension. I also suggest we add text to the effect of "If completeLoc= ation or similarLocation is included in the findService response, the profi= le MUST be the same as that of the location in the request that is used to = generate the findService response." Also, section 4 states: completeLocation and similarLocation use the locationInformation element from [RFC5222] including th= e profile attribute which is useful if the request contains location information in a profile derived from the civic profile. However, locationInformation is only a pattern defined in the schema in RFC= 5222, borrowed and reused here, not an actual element. Suggest changing th= e wording from "element" to "pattern". 5) I would like to suggest that each element that users the locationInformatio= n pattern should only represent one location. That is, instead of a single= similarLocation element containing multiple civicAddress elements (as illu= strated in the example), multiple similarLocation elements should be used w= ith each containing a single civicAddress. I am continuing to review this draft and may have additional comments. Dan Banks --_000_MWHPR17MB107171FFC603A9DA683B5DBFA7C70MWHPR17MB1071namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have been working on an implementation of the similar lo= cation mechanism described by draft-ietf-ecrit-similar-location-03, and hav= e some feedback:

 

1)

For completeLocation, the actual element name in the schem= a is “completedlocation”, with a ‘d’ and lowercase = ‘l’.  It appears this should be “completeLocation= 221;.  There is also a use of “completedLocation” on page 5 that should be changed. = Also, there will only be a single completeLocation returned.

 

   ##

   ##       comple= teLocation

   ##

   div {

     completeLocation =3D

       element completedlocation {

         locationI= nformation

       }+

   }

 

Should be:

 

   ##

   ##       comple= teLocation

   ##

   div {

     completeLocation =3D

       element completeLocation {

         locationI= nformation

       }

   }

 

2)

An element “returnedLocationResponse” is= defined by the schema, but not discussed in the text or illustrated in the= examples:

 

   div {
     returnedLocationResponse =3D
       element returnedLocationResponse =
{
         completeLocation, sim=
ilarLocation, extensionPoint
       }
   }

 

Perhaps we need a better way state that completeLoca= tion or similarLocation elements can be placed at the existing extension po= int within the LoST locationValidation element.

 

3)

It is desirable to have away for a client to specifi= cally request RLI, instead of it being included any time that validation is= performed.  Responses with multiple similar locations can quickly bec= ome large compared to responses without RLI, and may also incur additional processing cost at the server.  Th= is could be wasteful if automated validation is being performed or if the R= LI is otherwise not understood or discarded.  I suggest an attribute b= e added to the findService request (perhaps rli:returnLocation) with defined values of { “none” | “s= imilar”  | “complete” | “any” } to indic= ate which return location types the client is interested in.  Further,= I suggest that the server be restricted to including only RLI types in the= response that are requested, and that omitting the attribute from the request is equival= ent to rli:returnLocation=3D”none”.

 

4)

The text and schema state that the similarLocation a= nd completeLocation elements include the “profile” attribute, b= ut this is not shown in the examples.  RFC5222 makes the profile attri= bute optional in location chunks.  On the server side, this means that any location chunks without a profile attribute need to be= further analyzed to see if they can be recognized, which is an unnecessary= complication.  On the client side, the response pertains to one parti= cular location in the request (indicated by <locationUsed>), so the profile could be assumed from that, but I= would much rather have it be explicit.

 

I suggest we make the profile attribute mandatory wh= ere it is used within this extension.  I also suggest we add text to t= he effect of “If completeLocation or similarLocation is included in t= he findService response, the profile MUST be the same as that of the location in the request that is used to generate t= he findService response.”

 

Also, section 4 states:

   completeLocation and similarLocation use the locationInfo=
rmation
   element from [RFC5222] including the profile attribute which is
   useful if the request contains location information in a =
profile
   derived from the civic profile.

 

However, locationInformation is only a pattern defin= ed in the schema in RFC5222, borrowed and reused here, not an actual elemen= t.  Suggest changing the wording from “element” to “= pattern”.

 

5)

I would like to suggest that each element that users= the locationInformation pattern should only represent one location.  = That is, instead of a single similarLocation element containing multiple ci= vicAddress elements (as illustrated in the example), multiple similarLocation elements should be used with each c= ontaining a single civicAddress.

 

I am continuing to review this draft and may have ad= ditional comments.

 

Dan Banks

--_000_MWHPR17MB107171FFC603A9DA683B5DBFA7C70MWHPR17MB1071namp_-- From nobody Fri Oct 7 07:25:31 2016 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 102CF12960E for ; Fri, 7 Oct 2016 07:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 CxoUx9nOPLKP for ; Fri, 7 Oct 2016 07:25:27 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 E985512952D for ; Fri, 7 Oct 2016 07:25:26 -0700 (PDT) X-AuditID: c1b4fb25-5405a9800000793b-fc-57f7b055e6ed Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id 5F.14.31035.450B7F75; Fri, 7 Oct 2016 16:25:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0319.002; Fri, 7 Oct 2016 16:25:17 +0200 From: Christer Holmberg To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] Content-ID: Way forward without SIPCORE impact Thread-Index: AQHSH9FdW92vWNIey0OuUNcxPMNfjaCbbrcAgAGxcAA= Date: Fri, 7 Oct 2016 14:25:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <0178016C5C24C7448EFE8C57870A9218@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2J7lG7ohu/hBr92iVk0LnrKarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj24Lggv1cFVs/b2BvYDzF0cXIySEhYCKx emkncxcjF4eQwHpGiZmLZjODJIQEFjFKnD7t3sXIwcEmYCHR/U8bJCwi4C3x5/c3NhBbWMBZ YtW+QywQcReJJ/3djBC2lcTyhm/sIDaLgIrEowWPweK8AtYSK59sYYMYXygxZ/lPsBpOAQeJ FY39YDWMAmIS30+tYQKxmQXEJW49mc8EcaeAxJI955khbFGJl4//sYLYogJ6Et+/zoaKK0p8 fLWPEaJXR2LB7k9sELa1RP+OPnYIW1ti2cLXzBD3CEqcnPmEZQKj2Cwk62YhaZ+FpH0WkvZZ SNoXMLKuYhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAiMqYNbfqvuYLz8xvEQowAHoxIP74OI b+FCrIllxZW5hxglOJiVRHgL1n4PF+JNSaysSi3Kjy8qzUktPsQozcGiJM5rtvJ+uJBAemJJ anZqakFqEUyWiYNTqoGxinPW75/P7/gJ3jz3Wd5T01PDqtbk2HF7k6hrkiJGZfMXCBf5TVVw v+d/1uygwb9Yt+ehp6Mfaa5wjXIpPLWe7alqmU9ywHqGxvLDffrT3Za/SN0nGHPDY2bsoY9d s2bvmdngeNntgFrqhYiH00RmuP7S7LtsL/y92P6c74rudOnpGjfY9E4qsRRnJBpqMRcVJwIA rBaM2KUCAAA= Archived-At: Subject: Re: [Ecrit] Content-ID: Way forward without SIPCORE impact X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 14:25:29 -0000 https://www.youtube.com/watch?v=3DK8E_zMLCRNg On 06/10/16 18:40, "Ecrit on behalf of Paul Kyzivat" wrote: >On 10/6/16 8:58 AM, Christer Holmberg wrote: >> Hi, >> >> One way to solve the Content-ID issue would be to ALWAYS use a multipart >> MIME, even if we only carry one body part. See example in section >> 12.2.2.3 of RFC 6086. > >This is certainly a possibility > > Thanks, > Paul > >> Another advantage would be that we would always the same >> Content-Disposition header field value for the MSD/control body parts. >> Currently the value is dependent on whether there are other body parts >> in the message or not, which is a little strange. So, the multipart/MIME >> would have C-D:info-package and the MSD/control body part would have >> C-D:by-reference. >> >> Comments? >> >> Regards, >> >> Christer >> >> (It may still be a good idea to define usage of Content-ID for SIP, but >> then the ECRIT specs would not be held up due to that work) >> >> >> _______________________________________________ >> 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 From nobody Fri Oct 7 10:07:40 2016 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 74FE1129683 for ; Fri, 7 Oct 2016 10:07:38 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 wdM6f3QDmzv1 for ; Fri, 7 Oct 2016 10:07:37 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id E095C12967D for ; Fri, 7 Oct 2016 10:07:36 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 7 Oct 2016 10:07:36 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Fri, 7 Oct 2016 10:07:34 -0700 To: Christer Holmberg , "ecrit@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Ecrit] Content-ID: Way forward without SIPCORE impact X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 17:07:38 -0000 At 12:58 PM +0000 10/6/16, Christer Holmberg wrote: > Hi, > > One way to solve the Content-ID issue would be to ALWAYS use a > multipart MIME, even if we only carry one body part. See example in > section 12.2.2.3 of RFC 6086. > > Another advantage would be that we would always the same > Content-Disposition header field value for the MSD/control body > parts. Currently the value is dependent on whether there are other > body parts in the message or not, which is a little strange. So, > the multipart/MIME would have C-D:info-package and the MSD/control > body part would have C-D:by-reference. > > Comments? > > Regards, > > Christer > > (It may still be a good idea to define usage of Content-ID for SIP, > but then the ECRIT specs would not be held up due to that work) Hi Christer, In view of the slow progress of your draft, I think the proposal to always use a multipart is the best option. As you say, it simplifies the implementation because the C-D will always be "By-Reference". (As I recall, the same idea was floated some time back, during the discussion about INFO.) I agree that your draft should still progress, as it seems an oversight that C-ID is not included. --Randy -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Red Tape Holds Up New Bridge --Newspaper headline From nobody Sun Oct 9 01:55:31 2016 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 85AB212943D for ; Sun, 9 Oct 2016 01:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 9ZuL5F7scECS for ; Sun, 9 Oct 2016 01:55:28 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 E9411129426 for ; Sun, 9 Oct 2016 01:55:27 -0700 (PDT) X-AuditID: c1b4fb3a-aa3ff7000000099a-3d-57fa05fdfbea Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 57.16.02458.DF50AF75; Sun, 9 Oct 2016 10:55:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0319.002; Sun, 9 Oct 2016 10:55:25 +0200 From: Christer Holmberg To: Randall Gellens , "ecrit@ietf.org" Thread-Topic: [Ecrit] Content-ID: Way forward without SIPCORE impact Thread-Index: AQHSH9FdW92vWNIey0OuUNcxPMNfjaCdGW0AgAK68TA= Date: Sun, 9 Oct 2016 08:55:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BD3C7DF@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2K7k+4/1l/hBrMaJS0aFz1ltfj+vIvR gcljyZKfTB5b7zxmCWCK4rJJSc3JLEst0rdL4Mq40D6ZsaCVs+LnEs0GxpnsXYycHBICJhK7 nv5g6WLk4hASWM8osfvRdTYIZzGjxKrOhcxdjBwcbAIWEt3/tEFMEYEQiZb3XCC9wgLOEh9X 7mEGsUUEXCSe9HczQthWEhOu3mQFsVkEVCQ6tq9mArF5BXwl+lf1gcWFBFIllrXvZwGxOYFu aLq7EyzOKCAm8f3UGrB6ZgFxiVtP5jNB3CkgsWTPeWYIW1Ti5eN/rBC2ksSi25+h6nUkFuz+ xAZha0ssW/iaGWKvoMTJmU9YJjCKzEIydhaSlllIWmYhaVnAyLKKUbQ4tbg4N93ISC+1KDO5 uDg/Ty8vtWQTIzAWDm75bbWD8eBzx0OMAhyMSjy8D+78DBdiTSwrrsw9xCjBwawkwvuN6Ve4 EG9KYmVValF+fFFpTmrxIUZpDhYlcV6zlffDhQTSE0tSs1NTC1KLYLJMHJxSDYxBEW8T3xo2 1uy3yGd78kfFol9r/t/myETDOL7257cbtGR0VU9JCCmG7m5T/Prn54ZPyiYlPz5eu6Xw//39 7T9vdWqnZfz/9uGjlKoex0/5T6eq/RZcCOCQOPKm85iKgITv/1Zb64BF3ryPb0ZdfMb9bakH A88cudcLmtZMsnvEot9mHKYvdUiJpTgj0VCLuag4EQBECxkVgQIAAA== Archived-At: Subject: Re: [Ecrit] Content-ID: Way forward without SIPCORE impact X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 08:55:29 -0000 Hi, >> One way to solve the Content-ID issue would be to ALWAYS use a=20 >> multipart MIME, even if we only carry one body part. See example in=20 >> section 12.2.2.3 of RFC 6086. >> >> Another advantage would be that we would always the same=20 >> Content-Disposition header field value for the MSD/control body parts.=20 >> Currently the value is dependent on whether there are other body parts=20 >> in the message or not, which is a little strange. So, the=20 >> multipart/MIME would have C-D:info-package and the MSD/control body=20 >> part would have C-D:by-reference. > > In view of the slow progress of your draft, I think the proposal to=20 > always use a multipart is the best option. As you say, it simplifies=20 > the implementation because the C-D will always be "By-Reference". > > (As I recall, the same idea was floated some time back, during the=20 > discussion about INFO.) So, unless someone objects, I suggest we move forward with such approach.=20 Also, I'd like to see the a new version of the draft BEFORE the end of the = WGLC, so that I can perform a WGLC review based on that. Regards, Christer From nobody Sun Oct 9 12:13:38 2016 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 8AED412954F; Sun, 9 Oct 2016 12:13:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147604041656.30511.261237424752342807.idtracker@ietfa.amsl.com> Date: Sun, 09 Oct 2016 12:13:36 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-14.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 19:13:36 -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 of the IETF. Title : Next-Generation Vehicle-Initiated Emergency Calls Authors : Randall Gellens Brian Rosen Hannes Tschofenig Filename : draft-ietf-ecrit-car-crash-14.txt Pages : 42 Date : 2016-10-09 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data. This document also registers a MIME Content Type and Emergency Call Additional Data Block for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash). An external specification for the data format, contents, and structure are referenced in this document. This document reuses the technical aspects of next-generation pan- European eCall (a mandated and standardized system for emergency calls by in-vehicle systems within Europe and other regions). However, this document specifies a different set of vehicle (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This document is an extension of the eCall document, with the primary differences being that this document makes the MSD data set optional and VEDS mandatory, and adds attribute values to the eCall metadata/control object to permit greater functionality. This document registers a new INFO package (identical to that registered for eCall but with the addition of the VEDS MIME type). This document also describes legacy (circuit- switched) ACN systems and their migration to next-generation emergency calling, to provide background information and context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-14 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 Sun Oct 9 12:14:01 2016 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 6F5201295B2; Sun, 9 Oct 2016 12:13:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147604043144.30581.11604750137300942059.idtracker@ietfa.amsl.com> Date: Sun, 09 Oct 2016 12:13:51 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-15.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 19:13:51 -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 of the IETF. Title : Next-Generation Pan-European eCall Authors : Randall Gellens Hannes Tschofenig Filename : draft-ietf-ecrit-ecall-15.txt Pages : 44 Date : 2016-10-09 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of the Pan European in- vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles, providing real-time communications and an integrated set of related data. This document also registers MIME Content Types and an Emergency Call Additional Data Blocks for the eCall vehicle data and metadata/ control data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-ecall-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-15 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 Sun Oct 9 12:20:10 2016 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 75C6C129592 for ; Sun, 9 Oct 2016 12:20:09 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] autolearn=unavailable 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 cv62Aeer-rQ1 for ; Sun, 9 Oct 2016 12:20:08 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 68B0D129503 for ; Sun, 9 Oct 2016 12:14:43 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 9 Oct 2016 12:14:42 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BD3C7DF@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BD3C7DF@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Sun, 9 Oct 2016 12:14:40 -0700 To: Christer Holmberg , "ecrit@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Ecrit] Content-ID: Way forward without SIPCORE impact X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 19:20:09 -0000 At 8:55 AM +0000 10/9/16, Christer Holmberg wrote: > Hi, > >>> One way to solve the Content-ID issue would be to ALWAYS use a >>> multipart MIME, even if we only carry one body part. See example in >>> section 12.2.2.3 of RFC 6086. >>> >>> Another advantage would be that we would always the same >>> Content-Disposition header field value for the MSD/control body parts. >>> Currently the value is dependent on whether there are other body parts >>> in the message or not, which is a little strange. So, the >>> multipart/MIME would have C-D:info-package and the MSD/control body >>> part would have C-D:by-reference. >> >> In view of the slow progress of your draft, I think the proposal to >> always use a multipart is the best option. As you say, it simplifies >> the implementation because the C-D will always be "By-Reference". >> >> (As I recall, the same idea was floated some time back, during the >> discussion about INFO.) > > So, unless someone objects, I suggest we move forward with such approach. > > Also, I'd like to see the a new version of the draft BEFORE the end > of the WGLC, so that I can perform a WGLC review based on that. Now available. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- When a man's best friend is his dog, that dog has a problem. --Edward Abbey From nobody Tue Oct 11 11:38:00 2016 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 E0068129586 for ; Tue, 11 Oct 2016 11:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 FrG9cWzehbp3 for ; Tue, 11 Oct 2016 11:37:52 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 34CC512968C for ; Tue, 11 Oct 2016 11:37:52 -0700 (PDT) X-AuditID: c1b4fb25-14bff7000000793b-55-57fd317c0a63 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id FD.3A.31035.C713DF75; Tue, 11 Oct 2016 20:37:50 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0319.002; Tue, 11 Oct 2016 20:37:48 +0200 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: Christer's review of draft-ietf-ecrit-ecall-15 (excluding Section 15) Thread-Index: AdIj7ogBtxDiAb8QSKmA7VS7QH+Pmg== Date: Tue, 11 Oct 2016 18:37:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BD5F5BF@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BD5F5BFESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM2K7k26d4d9wg1lnFSwaFz1ldWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqKNLgUt1RVfOtsZGxjPZXYxcnJICJhI/DncydrFyMUhJLCe UeJpy1soZwmjxLqDl4AcDg42AQuJ7n/aIA0iAqoSG86sZASxhQUCJKbNPMUIEQ+V+Huzjw3C 1pM4+LGNCcRmAar/86iLHcTmFfCVuDutkwXEZhQQk/h+ag1YDbOAuMStJ/OZIA4SkFiy5zwz hC0q8fLxP1YIW0micckTVoj6fImvy/czQswUlDg58wnLBEbBWUhGzUJSNgtJGURcT+LG1Cls ELa2xLKFr5khbF2JGf8OsSCLL2BkX8UoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGPgHt/xW 3cF4+Y3jIUYBDkYlHt4FGn/DhVgTy4orcw8xSnAwK4nwRhgAhXhTEiurUovy44tKc1KLDzFK c7AoifOarbwfLiSQnliSmp2aWpBaBJNl4uCUamAM+NHU+fyA6gMzkStrOzgS2v1cijd//LVr 8aVaVdE/plvvXBRxWfnJ77pb8dqfTg0bE96un20guPzj8fOL9Wufzk5PvZ4SvcxifY/q2/fv 21dmumlMPijkHy7s383NpPz68wftgti6Y/cvizqoNFypOMv1Lf/UrVlyap37Ntwp3lZ+9vxk v6fVSizFGYmGWsxFxYkAym0XaXgCAAA= Archived-At: Subject: [Ecrit] Christer's review of draft-ietf-ecrit-ecall-15 (excluding Section 15) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 18:37:55 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BD5F5BFESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Attached is my review of draft-ietf-ecrit-ecall-15. I have not reviewed Sec= tion 15. Note that some of my comments probably apply to draft-ietf-ecrit-car-crash = also, so I ask the authors to take that into consideration. Regards. Christer ---------- Q1: In Section 2, I suggest to change the title to "Applicability", because I t= hink that is what is normally used. Q2: In Section 2, you should expand "3GPP" and "CEN" on first occurrence. In ad= dition, I think there should be a reference with "3GPP IMS Emergency Callin= g". Q3: In Section 2, the text says: "The technical contents of this document also provide a basis for reuse and extension for other vehicle-initiated emergency call Systems. Vehicles designed for multiple regions might need to support eCall and other Advanced Automatic Crash Notification (AACN) systems, such as described in [I-D.ietf-ecrit-car-crash]." I don=B9t think the text is needed, but if you want to keep it you should e= xplicitly say that it=B9s outside the scope of the document. Q4: In Section 3, you first describe eCall in general, which is good. But then,= in the last paragraph, you suddenly start talking about MIME types. I thin= k you should add another chapter, giving a general overview of what the doc= ument does. I guess you can re-use text from the Abstract. Q5: In Section 5, I suggest to re-name the title to "MSD Format", or something = like that. Q6: In Section 6, please add references to the different SIP/MIME header fields= (Content-Type, Content-ID etc). Q7: In Section 6, the text says: "An MSD or a metadata/control block is always enclosed in a multipart body part (even if it would otherwise be the only body part in the SIP message)." We did agree on this for INFO, but is there a reason for doing this also in= non-INFO requests? Q8: In Section 6, the text says: "Note that in some cases there might be intermediate multipart body parts between the top level multipart and the body part containing the MSD or metadata/control object." I have no idea what that text means. Q9: In Section 9, I suggest to remove the bullet list. I don=B9t really underst= and why it is needed, and it=B9s unclear what "This mechanism" refers to. IF you want to list requirements associated with carrying control/metadata = I think it should be in a separate section. Q10: In Section 9, the text says: "if the IVS sends a requested MSD in an INFO request and does not receiv= e a SIP status message for the INFO request, it resends it; if the PSAP requests an MSD and does not receive a SIP status message for the INFO request, it resends it.)" This is basic SIP, and can be removed. Earlier you mention SIP re-transmis= sion, and that=B9s enough. I think you should add the following, though: =B3Note that, per RFC6086, a 200 OK response to the INFO request only in= dicates that the receiver has successfully received and accepted the INFO r= equest." Q11: In Section 9, the text says: "The SIP response codes 600 (Busy Everywhere), 486 (Busy Here), and 603 = (Decline) are used when the PSAP wants to reject a call but inform the vehicle occupants that it is aware of the situation." Please add a reference to where this is defined. Q12: In Section 10.6, please add explicit text that says that multipart is used = even if only a single body part is transported. You may even reference the = example in RFC 6086. Also add explicit text saying that =B3Per RFC 6086, th= e content disposition value of the multipart MIME is 'info-package', or som= ething like that. Q13: In Section 10.6, similar to my earlier comment, I don=B9t understand the te= xt about "intermediary body parts". Q14: In Section 11, you should add the Content-Disposition SIP header field (wit= h 'info-package' value) to the INFO requests. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4BD5F5BFESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

Attached is my review of draft-ietf-ecrit-ecall-15. = I have not reviewed Section 15.

 

Note that some of my comments probably apply to draf= t-ietf-ecrit-car-crash also, so I ask the authors to take that into conside= ration.

 

Regards.

 

Christer

 

----------

 

Q1:

 

In Section 2, I suggest to change the title to ̶= 0;Applicability”, because I think that is what is normally used.=

 

 

Q2:

 

In Section 2, you should expand “3GPP” a= nd “CEN” on first occurrence. In addition, I think there should= be a reference with "3GPP IMS Emergency Calling”.

 

 

Q3:

 

In Section 2, the text says:

 

   "The technical contents of this do= cument also provide a basis for

   reuse and extension for other vehicle-i= nitiated emergency call

   Systems.

 

   Vehicles designed for multiple regions = might need to support eCall

   and other Advanced Automatic Crash Noti= fication (AACN) systems, such

   as described in [I-D.ietf-ecrit-car-cra= sh].”

 

I don=B9t think the text is needed, but if you want = to keep it you should explicitly say that it=B9s outside the scope of the d= ocument.

 

 

Q4:

 

In Section 3, you first describe eCall in general, w= hich is good. But then, in the last paragraph, you suddenly start talking a= bout MIME types. I think you should add another chapter, giving a general o= verview of what the document does. I guess you can re-use text from the Abstract.

 

 

Q5:

 

In Section 5, I suggest to re-name the title to R= 20;MSD Format”, or something like that.

 

 

Q6:

 

In Section 6, please add references to the different= SIP/MIME header fields (Content-Type, Content-ID etc).

 

 

Q7:

 

In Section 6, the text says:

 

   "An MSD or a metadata/control bloc= k is always enclosed in a multipart

   body part (even if it would otherwise b= e the only body part in the

   SIP message)."

 

We did agree on this for INFO, but is there a reason= for doing this also in non-INFO requests?

 

 

Q8:

 

In Section 6, the text says:

 

   "Note that in some cases there mig= ht be intermediate

   multipart body parts between the top le= vel multipart and the body

   part containing the MSD or metadata/con= trol object."

 

I have no idea what that text means.

 

 

Q9:

 

In Section 9, I suggest to remove the bullet list. I= don=B9t really understand why it is needed, and it=B9s unclear what “= ;This mechanism” refers to.

IF you want to list requirements associated with car= rying control/metadata I think it should be in a separate section.

 

 

Q10:

 

In Section 9, the text says:

 

   "if the IVS sends a requested MSD = in an INFO request and does not receive a SIP

   status message for the INFO request, it= resends it; if the PSAP

   requests an MSD and does not receive a = SIP status message for the

   INFO request, it resends it.)"

 

This is basic SIP,  and can be removed. Earlier= you mention SIP re-transmission, and that=B9s enough. I think you should a= dd the following, though:

 

   =B3Note that, per RFC6086, a 200 OK res= ponse to the INFO request only indicates that the receiver has successfully= received and accepted the INFO request."

 

 

Q11:

 

In Section 9, the text says:

 

   "The SIP response codes 600 (Busy = Everywhere), 486 (Busy Here), and 603 (Decline) are used when

   the PSAP wants to reject a call but inf= orm the vehicle occupants that

   it is aware of the situation."&nbs= p;

 

Please add a reference to where this is defined.

 

 

Q12:

 

In Section 10.6, please add explicit text that says = that multipart is used even if only a single body part is transported. You = may even reference the example in RFC 6086. Also add explicit text saying t= hat =B3Per RFC 6086, the content disposition value of the multipart MIME is ‘info-package’, or something li= ke that.

 

 

Q13:

 

In Section 10.6, similar to my earlier comment, I do= n=B9t understand the text about “intermediary body parts”.=

 

 

Q14:

 

In Section 11, you should add the Content-Dispositio= n SIP header field (with ‘info-package’ value) to the INFO requ= ests.

 

Regards,

 

Christer

 

 

--_000_7594FB04B1934943A5C02806D1A2204B4BD5F5BFESESSMB209erics_-- From nobody Tue Oct 11 11:44:59 2016 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 D3D29129695 for ; Tue, 11 Oct 2016 11:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 F3x82bIEXozS for ; Tue, 11 Oct 2016 11:44:55 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 047FA129696 for ; Tue, 11 Oct 2016 11:44:54 -0700 (PDT) X-AuditID: c1b4fb25-5405a9800000793b-bd-57fd33259d3e Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id A2.EA.31035.5233DF75; Tue, 11 Oct 2016 20:44:53 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0319.002; Tue, 11 Oct 2016 20:44:09 +0200 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: [Ecrit] Christer's review of draft-ietf-ecrit-ecall-15 (excluding Section 15) Thread-Index: AdIj7ogBtxDiAb8QSKmA7VS7QH+PmgAAN+zQ Date: Tue, 11 Oct 2016 18:44:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BD5F615@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BD5F5BF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BD5F5BF@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BD5F615ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7hK6q8d9wgxkPpSwaFz1ldWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxu8fq5kL9rcwVty5P5ulgbGlqIuRk0NCwERi2f6FLCC2kMB6 RonbfxK6GLmA7CWMEs8mbARKcHCwCVhIdP/TBqkREVCV2HBmJSOILSwQI/H/zgl2iHisxJH2 jywQtpHE7tV3WUFsFqD6S0sfsoKM4RXwlXjxoxTEFAIxN2uCVHAK+El07ZzBBGIzCohJfD+1 BsxmFhCXuPVkPhPElQISS/acZ4awRSVePv7HCmErSTQuecIKUZ8v0bHtHdgFvAKCEidnPmGZ wCg8C8moWUjKZiEpg4jrSdyYOoUNwtaWWLbwNTOErSsx498hFmTxBYzsqxhFi1OLk3LTjYz1 Uosyk4uL8/P08lJLNjEC4+Tglt+qOxgvv3E8xCjAwajEw7tA42+4EGtiWXFl7iFGCQ5mJRHe CAOgEG9KYmVValF+fFFpTmrxIUZpDhYlcV6zlffDhQTSE0tSs1NTC1KLYLJMHJxSDYxW9irM fR6xt2MPVCg5WeQ8Nkqs1AnuWHLj7IOjjq3OkxZoKoUr+0WdnGASbPXSgj+nPPOZnnD1Rbs1 B9KKt1dkC1ZvCV3lKTFRuU/f/c0k/1ObBFm7Tfy3uRgeMGXSqLrulL2Y/2SxnZr+H88zXvHW 25K1YthfGnUunPlx39E2+yDXg8f3KLEUZyQaajEXFScCACxJVT+PAgAA Archived-At: Subject: Re: [Ecrit] Christer's review of draft-ietf-ecrit-ecall-15 (excluding Section 15) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 18:44:58 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BD5F615ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Regarding Q4, I mean "add another PARAGRAPH" :) From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 11 October 2016 21:38 To: ecrit@ietf.org Subject: [Ecrit] Christer's review of draft-ietf-ecrit-ecall-15 (excluding = Section 15) Hi, Attached is my review of draft-ietf-ecrit-ecall-15. I have not reviewed Sec= tion 15. Note that some of my comments probably apply to draft-ietf-ecrit-car-crash = also, so I ask the authors to take that into consideration. Regards. Christer ---------- Q1: In Section 2, I suggest to change the title to "Applicability", because I t= hink that is what is normally used. Q2: In Section 2, you should expand "3GPP" and "CEN" on first occurrence. In ad= dition, I think there should be a reference with "3GPP IMS Emergency Callin= g". Q3: In Section 2, the text says: "The technical contents of this document also provide a basis for reuse and extension for other vehicle-initiated emergency call Systems. Vehicles designed for multiple regions might need to support eCall and other Advanced Automatic Crash Notification (AACN) systems, such as described in [I-D.ietf-ecrit-car-crash]." I don=B9t think the text is needed, but if you want to keep it you should e= xplicitly say that it=B9s outside the scope of the document. Q4: In Section 3, you first describe eCall in general, which is good. But then,= in the last paragraph, you suddenly start talking about MIME types. I thin= k you should add another chapter, giving a general overview of what the doc= ument does. I guess you can re-use text from the Abstract. Q5: In Section 5, I suggest to re-name the title to "MSD Format", or something = like that. Q6: In Section 6, please add references to the different SIP/MIME header fields= (Content-Type, Content-ID etc). Q7: In Section 6, the text says: "An MSD or a metadata/control block is always enclosed in a multipart body part (even if it would otherwise be the only body part in the SIP message)." We did agree on this for INFO, but is there a reason for doing this also in= non-INFO requests? Q8: In Section 6, the text says: "Note that in some cases there might be intermediate multipart body parts between the top level multipart and the body part containing the MSD or metadata/control object." I have no idea what that text means. Q9: In Section 9, I suggest to remove the bullet list. I don=B9t really underst= and why it is needed, and it=B9s unclear what "This mechanism" refers to. IF you want to list requirements associated with carrying control/metadata = I think it should be in a separate section. Q10: In Section 9, the text says: "if the IVS sends a requested MSD in an INFO request and does not receiv= e a SIP status message for the INFO request, it resends it; if the PSAP requests an MSD and does not receive a SIP status message for the INFO request, it resends it.)" This is basic SIP, and can be removed. Earlier you mention SIP re-transmis= sion, and that=B9s enough. I think you should add the following, though: =B3Note that, per RFC6086, a 200 OK response to the INFO request only in= dicates that the receiver has successfully received and accepted the INFO r= equest." Q11: In Section 9, the text says: "The SIP response codes 600 (Busy Everywhere), 486 (Busy Here), and 603 = (Decline) are used when the PSAP wants to reject a call but inform the vehicle occupants that it is aware of the situation." Please add a reference to where this is defined. Q12: In Section 10.6, please add explicit text that says that multipart is used = even if only a single body part is transported. You may even reference the = example in RFC 6086. Also add explicit text saying that =B3Per RFC 6086, th= e content disposition value of the multipart MIME is 'info-package', or som= ething like that. Q13: In Section 10.6, similar to my earlier comment, I don=B9t understand the te= xt about "intermediary body parts". Q14: In Section 11, you should add the Content-Disposition SIP header field (wit= h 'info-package' value) to the INFO requests. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4BD5F615ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Regarding Q4, I mean &= #8220;add another PARAGRAPH” :)

 

From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 11 October 2016 21:38
To: ecrit@ietf.org
Subject: [Ecrit] Christer's review of draft-ietf-ecrit-ecall-15 (exc= luding Section 15)

 

Hi,

 

Attached is my review of draft-ietf-ecrit-ecall-15. = I have not reviewed Section 15.

 

Note that some of my comments probably apply to draf= t-ietf-ecrit-car-crash also, so I ask the authors to take that into conside= ration.

 

Regards.

 

Christer

 

----------

 

Q1:

 

In Section 2, I suggest to change the title to ̶= 0;Applicability”, because I think that is what is normally used.=

 

 

Q2:

 

In Section 2, you should expand “3GPP” a= nd “CEN” on first occurrence. In addition, I think there should= be a reference with "3GPP IMS Emergency Calling”.

 

 

Q3:

 

In Section 2, the text says:

 

   "The technical contents of this do= cument also provide a basis for

   reuse and extension for other vehicle-i= nitiated emergency call

   Systems.

 

   Vehicles designed for multiple regions = might need to support eCall

   and other Advanced Automatic Crash Noti= fication (AACN) systems, such

   as described in [I-D.ietf-ecrit-car-cra= sh].”

 

I don=B9t think the text is needed, but if you want = to keep it you should explicitly say that it=B9s outside the scope of the d= ocument.

 

 

Q4:

 

In Section 3, you first describe eCall in general, w= hich is good. But then, in the last paragraph, you suddenly start talking a= bout MIME types. I think you should add another chapter, giving a general o= verview of what the document does. I guess you can re-use text from the Abstract.

 

 

Q5:

 

In Section 5, I suggest to re-name the title to R= 20;MSD Format”, or something like that.

 

 

Q6:

 

In Section 6, please add references to the different= SIP/MIME header fields (Content-Type, Content-ID etc).

 

 

Q7:

 

In Section 6, the text says:

 

   "An MSD or a metadata/control bloc= k is always enclosed in a multipart

   body part (even if it would otherwise b= e the only body part in the

   SIP message)."

 

We did agree on this for INFO, but is there a reason= for doing this also in non-INFO requests?

 

 

Q8:

 

In Section 6, the text says:

 

   "Note that in some cases there mig= ht be intermediate

   multipart body parts between the top le= vel multipart and the body

   part containing the MSD or metadata/con= trol object."

 

I have no idea what that text means.

 

 

Q9:

 

In Section 9, I suggest to remove the bullet list. I= don=B9t really understand why it is needed, and it=B9s unclear what “= ;This mechanism” refers to.

IF you want to list requirements associated with car= rying control/metadata I think it should be in a separate section.

 

 

Q10:

 

In Section 9, the text says:

 

   "if the IVS sends a requested MSD = in an INFO request and does not receive a SIP

   status message for the INFO request, it= resends it; if the PSAP

   requests an MSD and does not receive a = SIP status message for the

   INFO request, it resends it.)"

 

This is basic SIP,  and can be removed. Earlier= you mention SIP re-transmission, and that=B9s enough. I think you should a= dd the following, though:

 

   =B3Note that, per RFC6086, a 200 OK res= ponse to the INFO request only indicates that the receiver has successfully= received and accepted the INFO request."

 

 

Q11:

 

In Section 9, the text says:

 

   "The SIP response codes 600 (Busy = Everywhere), 486 (Busy Here), and 603 (Decline) are used when

   the PSAP wants to reject a call but inf= orm the vehicle occupants that

   it is aware of the situation."&nbs= p;

 

Please add a reference to where this is defined.

 

 

Q12:

 

In Section 10.6, please add explicit text that says = that multipart is used even if only a single body part is transported. You = may even reference the example in RFC 6086. Also add explicit text saying t= hat =B3Per RFC 6086, the content disposition value of the multipart MIME is ‘info-package’, or something li= ke that.

 

 

Q13:

 

In Section 10.6, similar to my earlier comment, I do= n=B9t understand the text about “intermediary body parts”.=

 

 

Q14:

 

In Section 11, you should add the Content-Dispositio= n SIP header field (with ‘info-package’ value) to the INFO requ= ests.

 

Regards,

 

Christer

 

 

--_000_7594FB04B1934943A5C02806D1A2204B4BD5F615ESESSMB209erics_-- From nobody Tue Oct 11 15:56:32 2016 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 73C7512965A for ; Tue, 11 Oct 2016 15:56:30 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 c1DSYcZkK9vH for ; Tue, 11 Oct 2016 15:56:28 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 60E68129608 for ; Tue, 11 Oct 2016 15:56:28 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 11 Oct 2016 15:56:27 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BD5F615@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BD5F5BF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BD5F615@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Tue, 11 Oct 2016 15:56:24 -0700 To: Christer Holmberg , "ecrit@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Ecrit] Christer's review of draft-ietf-ecrit-ecall-15 (excluding Section 15) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 22:56:30 -0000 Hi Christer, Thanks for your review. Please see initial answers (before I've edited the draft) below. --Randy At 6:44 PM +0000 10/11/16, Christer Holmberg wrote: > Regarding Q4, I mean "add another PARAGRAPH" :) > > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 11 October 2016 21:38 > To: ecrit@ietf.org > Subject: [Ecrit] Christer's review of draft-ietf-ecrit-ecall-15 > (excluding Section 15) > > Hi, > > Attached is my review of draft-ietf-ecrit-ecall-15. I have not > reviewed Section 15. > > Note that some of my comments probably apply to > draft-ietf-ecrit-car-crash also, so I ask the authors to take that > into consideration. > > Regards. > > Christer > > ---------- > > Q1: > > In Section 2, I suggest to change the title to "Applicability", > because I think that is what is normally used. I've always used "Document Scope" for this material (e.g., see RFC 7852). > Q2: > > In Section 2, you should expand "3GPP" and "CEN" on first > occurrence. In addition, I think there should be a reference with > "3GPP IMS Emergency Calling". Good suggestion, thanks, I'll add these. > > > Q3: > > In Section 2, the text says: > > "The technical contents of this document also provide a basis for > reuse and extension for other vehicle-initiated emergency call > Systems. > > Vehicles designed for multiple regions might need to support eCall > and other Advanced Automatic Crash Notification (AACN) systems, such > as described in [I-D.ietf-ecrit-car-crash]." > > I don't think the text is needed, but if you want to keep it you > should explicitly say that it's outside the scope of the document. I think the first sentence helps explain the expansion items (e.g., used by the car-crash draft), and the second was added by request of Keith a year or two ago; I'm happy to reword both sentences to make it more clear that this is background info. > Q4: > > In Section 3, you first describe eCall in general, which is good. > But then, in the last paragraph, you suddenly start talking about > MIME types. I think you should add another chapter, giving a > general overview of what the document does. I guess you can re-use > text from the Abstract. I see your point. I'll add another paragraph saying what the draft does, to provide a smoother transition into the one about the MIME types. > Q5: > > In Section 5, I suggest to re-name the title to "MSD Format", or > something like that. What is your concern with the current title? To me, "Vehicle Data" is more general and hence easier to understand for someone who doesn't know what an MSD is. The text explains that the data is called an MSD. How about if I add "(MSD)" to the title? That way, someone who knows they are looking for the MSD info can find it, and someone who doesn't know what an MSD is will know what the section is about. > Q6: > > In Section 6, please add references to the different SIP/MIME > header fields (Content-Type, Content-ID etc). We have multiple references to RFC 7852. Do you think we need to also reference RFC 3261 for Call-Info and RFC 2045 and/or RFC 2392 for Content-ID and RFC 2045 for Content-Type and Content-Disposition? > Q7: > > In Section 6, the text says: > > "An MSD or a metadata/control block is always enclosed in a multipart > body part (even if it would otherwise be the only body part in the > SIP message)." > > We did agree on this for INFO, but is there a reason for doing this > also in non-INFO requests? I suspect so, and it's the same reason: so that Content-ID is valid. (In reality, I can't imagine that an MSD would be the only body part in an initial INVITE, but I think we need to say so just in case.) > Q8: > > In Section 6, the text says: > > "Note that in some cases there might be intermediate > multipart body parts between the top level multipart and the body > part containing the MSD or metadata/control object." > > I have no idea what that text means. It's just trying to note that there might be multiple levels of multipart. I'll reword this to make it simpler. > Q9: > > In Section 9, I suggest to remove the bullet list. I don't really > understand why it is needed, and it's unclear what "This mechanism" > refers to. > IF you want to list requirements associated with carrying > control/metadata I think it should be in a separate section. I think you're right that the bullet list and some surrounding text can be deleted. > Q10: > > In Section 9, the text says: > > "if the IVS sends a requested MSD in an INFO request and does > not receive a SIP > status message for the INFO request, it resends it; if the PSAP > requests an MSD and does not receive a SIP status message for the > INFO request, it resends it.)" > > This is basic SIP, and can be removed. Earlier you mention SIP > re-transmission, and that's enough. I think you should add the > following, though: > > "Note that, per RFC6086, a 200 OK response to the INFO request > only indicates that the receiver has successfully received and > accepted the INFO request." I'm happy to delete the text after "Normal SIP retransmission handles non-receipt of requested data". I agree it isn't needed. Is there specific text that you think is potentially confusing and hence needs the note about the semantics of a 200 OK? > Q11: > > In Section 9, the text says: > > "The SIP response codes 600 (Busy Everywhere), 486 (Busy Here), > and 603 (Decline) are used when > the PSAP wants to reject a call but inform the vehicle occupants that > it is aware of the situation." > > Please add a reference to where this is defined. I'll reword this text. > Q12: > > In Section 10.6, please add explicit text that says that multipart > is used even if only a single body part is transported. I'll add text to make it more explicit. > You may even reference the example in RFC 6086. Also add explicit > text saying that "Per RFC 6086, the content disposition value of > the multipart MIME is 'info-package', or something like that. We had an email discussion about this some weeks back, and Paul pointed out that it wasn't always correct for the top level multipart to have a Content-Disposition of INFO-Package. > > > Q13: > > In Section 10.6, similar to my earlier comment, I don't understand > the text about "intermediary body parts". I'll fix this as above. > Q14: > > In Section 11, you should add the Content-Disposition SIP header > field (with 'info-package' value) to the INFO requests. In the email discussion, Paul said it was better to leave it off. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The Pledge of Allegiance says `liberty and justice for all'. Which part of `all' don't you understand? --Rep. Pat Schroeder (D) Colorado From nobody Tue Oct 11 20:25:23 2016 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 5533E12943E for ; Tue, 11 Oct 2016 20:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 Cqa0_ibaa3L9 for ; Tue, 11 Oct 2016 20:25:20 -0700 (PDT) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (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 C2CFC1293EB for ; Tue, 11 Oct 2016 20:25:20 -0700 (PDT) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-02v.sys.comcast.net with SMTP id uA9xbWUnM1zBduAARbPmiK; Wed, 12 Oct 2016 03:25:19 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-10v.sys.comcast.net with SMTP id uAAQbwE42mXyiuAAQbHizh; Wed, 12 Oct 2016 03:25:19 +0000 To: Randall Gellens , Christer Holmberg , "ecrit@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B4BD5F5BF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BD5F615@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: Date: Tue, 11 Oct 2016 23:25:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfG1KZ3/f5n2SLk11h2wXo4GS59UjN8lO19KphbZTbSk4yUnFiYSYYeVTTdJfvkjNENTPOBrHxg7iMZJOHRQAQNoNRlvwXoSuLf0rLSqIBZ0gmn9cKcq3 yKDKVEnSvsWjb22dF953p/vQ8ZSD32Zgxt81bex09GVKDNgFaW7LHJsoqPxLhRko4EsqEOFfJG5Lv8Blsfuqpi4PxYgXhIPv3Dj62RNL2CAkkC3r5IrINXKk r9vR5/KcvYa7DdI2i3sGiw== Archived-At: Subject: Re: [Ecrit] Christer's review of draft-ietf-ecrit-ecall-15 (excluding Section 15) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 03:25:22 -0000 On 10/11/16 6:56 PM, Randall Gellens wrote: > I suspect so, and it's the same reason: so that Content-ID is valid. (In > reality, I can't imagine that an MSD would be the only body part in an > initial INVITE, but I think we need to say so just in case.) I wonder how many implementations will break when they get an INVITE with a multipart body but no offer included. :-) From nobody Tue Oct 11 23:37:32 2016 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 ED2E01295C7 for ; Tue, 11 Oct 2016 23:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 Bzt3Ek_NwNoN for ; Tue, 11 Oct 2016 23:37:28 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 8D3BE129404 for ; Tue, 11 Oct 2016 23:37:28 -0700 (PDT) X-AuditID: c1b4fb30-b73ff70000000cb2-e1-57fdda251d92 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id ED.D6.03250.52ADDF75; Wed, 12 Oct 2016 08:37:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0319.002; Wed, 12 Oct 2016 08:37:25 +0200 From: Christer Holmberg To: Randall Gellens , "ecrit@ietf.org" Thread-Topic: [Ecrit] Christer's review of draft-ietf-ecrit-ecall-15 (excluding Section 15) Thread-Index: AQHSJFMXCWepAklJakmhJ5rtbIgLzQ== Date: Wed, 12 Oct 2016 06:37:24 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BD5F5BF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BD5F615@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2J7lK7arb/hBrN36lk0LnrKarFiwwFW i+/PuxgdmD3+vv/A5LFkyU8mj613HrMEMEdx2aSk5mSWpRbp2yVwZRw9e4+p4Kdhxf7pPxkb GA+rdTFyckgImEic2LWXpYuRi0NIYD2jxOFVxxkhnCWMEpdmbGbuYuTgYBOwkOj+pw1iigiE SLS85wLpZRbQkLh8u4sNxBYWiJXY9ukPK4gtIhAncWTXPjYIW0/iysnL7CA2i4CqxIqOB2Bx XgFriZYTW6H27maUePTwIliCE+igxZt+gA1iFBCT+H5qDRPEMnGJW0/mM0EcLSCxZM95Zghb VOLl439g9aJAy75/nQ0VV5S4On05VK+exI2pU9ggbGuJkwfPs0DY2hLLFr5mhjhIUOLkzCcs ExjFZyFZNwtJ+ywk7bOQtM9C0r6AkXUVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmAMHtzy 22AH48vnjocYBTgYlXh4F2j8DRdiTSwrrsw9xCjBwawkwqt2FSjEm5JYWZValB9fVJqTWnyI UZqDRUmc12zl/XAhgfTEktTs1NSC1CKYLBMHp1QD49wnn6cp+feIcQTNX/n28tf/0UYyvFY/ jBfc2cR3Y6fJlV6OVNfbk04v+RaSKPme4YLOrbdBBnePZzh0FE7RVf/kWXxrqaKp/xr5t1XL 7kUVWghe3duiv7b9/p8VL2Qu5O3jY4ievnLbGsuVq7d7XJ3lXj15hbwVe9Tp4MYji2VKW6/y PFLSq1FiKc5INNRiLipOBAC1bQfUvQIAAA== Archived-At: Subject: Re: [Ecrit] Christer's review of draft-ietf-ecrit-ecall-15 (excluding Section 15) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 06:37:31 -0000 Hi, Please see inline: >> Q3: >> >> In Section 2, the text says: >> >> "The technical contents of this document also provide a basis for >> reuse and extension for other vehicle-initiated emergency call >> Systems. >> >> Vehicles designed for multiple regions might need to support eCall >> and other Advanced Automatic Crash Notification (AACN) systems, such >> as described in [I-D.ietf-ecrit-car-crash]." >> >> I don't think the text is needed, but if you want to keep it you >> should explicitly say that it's outside the scope of the document. > >I think the first sentence helps explain the expansion items (e.g., >used by the car-crash draft), and the second was added by request of >Keith a year or two ago; I'm happy to reword both sentences to make >it more clear that this is background info. I just want to make it clear that none of the above is something that is covered in THIS document. >> Q5: >> >> In Section 5, I suggest to re-name the title to "MSD Format", or >> something like that. > >What is your concern with the current title? To me, "Vehicle Data" >is more general and hence easier to understand for someone who >doesn't know what an MSD is. The text explains that the data is >called an MSD. How about if I add "(MSD)" to the title? That way, >someone who knows they are looking for the MSD info can find it, and >someone who doesn't know what an MSD is will know what the section is >about. I was thinking more about this, and I=B9m ok with the current title. >> Q6: >> >> In Section 6, please add references to the different SIP/MIME >> header fields (Content-Type, Content-ID etc). > >We have multiple references to RFC 7852. Do you think we need to >also reference RFC 3261 for Call-Info and RFC 2045 and/or RFC 2392 >for Content-ID and RFC 2045 for Content-Type and Content-Disposition? I think it would be good to have a reference on first occurrence, especially since some header fields aren=B9t SIP header fields. >> Q7: >> >> In Section 6, the text says: >> >> "An MSD or a metadata/control block is always enclosed in a >>multipart >> body part (even if it would otherwise be the only body part in the >> SIP message)." >> >> We did agree on this for INFO, but is there a reason for doing this >> also in non-INFO requests? > >I suspect so, and it's the same reason: so that Content-ID is valid. >(In reality, I can't imagine that an MSD would be the only body part >in an initial INVITE, but I think we need to say so just in case.) You are right. Maybe it would be good to add a note saying that the reason is that, at the time of writing the document, the usage of Content-ID as a SIP header field was not defined. I DO agree that, in most cases, MSD will not be the only body part in the INVITE. >> Q8: >> >> In Section 6, the text says: >> >> "Note that in some cases there might be intermediate >> multipart body parts between the top level multipart and the body >> part containing the MSD or metadata/control object." >> >> I have no idea what that text means. > >It's just trying to note that there might be multiple levels of >multipart. I'll reword this to make it simpler. I don=B9t think we need to say anything. It=B9s basic multipart handling, a= nd we don=B9t define any procedures that mandates multiple levels, so... >> Q10: >> >> In Section 9, the text says: >> >> "if the IVS sends a requested MSD in an INFO request and does >> not receive a SIP >> status message for the INFO request, it resends it; if the PSAP >> requests an MSD and does not receive a SIP status message for the >> INFO request, it resends it.)" >> >> This is basic SIP, and can be removed. Earlier you mention SIP >> re-transmission, and that's enough. I think you should add the >> following, though: >> >> "Note that, per RFC6086, a 200 OK response to the INFO request >> only indicates that the receiver has successfully received and >> accepted the INFO request." > >I'm happy to delete the text after "Normal SIP retransmission handles >non-receipt of requested data". I agree it isn't needed. > >Is there specific text that you think is potentially confusing and >hence needs the note about the semantics of a 200 OK? Some may think that 200 OK means that the ecall application accepted the MSD. MSD only means that the receiving SIP stack accepted the INFO. >> Q11: >> >> In Section 9, the text says: >> >> "The SIP response codes 600 (Busy Everywhere), 486 (Busy Here), >> and 603 (Decline) are used when >> the PSAP wants to reject a call but inform the vehicle occupants >>that >> it is aware of the situation." >> >> Please add a reference to where this is defined. > >I'll reword this text. My question was not about the wording - it was more about where this is defined. I.e., is this something you define for ecall, or it is something generic defined elsewhere? >> Q12: >> >> In Section 10.6, please add explicit text that says that multipart >> is used even if only a single body part is transported. > >I'll add text to make it more explicit. > >> You may even reference the example in RFC 6086. Also add explicit >> text saying that "Per RFC 6086, the content disposition value of >> the multipart MIME is 'info-package', or something like that. > >We had an email discussion about this some weeks back, and Paul >pointed out that it wasn't always correct for the top level multipart >to have a Content-Disposition of INFO-Package. The C-D of the multipart which contains the ecall body part(s) shall be info-package. Perhaps that multipart is within another multipart, but that=B9s a separate issue. >> Q14: >> >> In Section 11, you should add the Content-Disposition SIP header >> field (with 'info-package' value) to the INFO requests. > >In the email discussion, Paul said it was better to leave it off. I don=B9t agree. These specific examples are cases where the INFO only contains ecall information, which is the normal case. If people also want to add an example where the INFO also contains non-ecall stuff, we can do that, even though I don=B9t think it=B9s needed. Regards, Christer From nobody Wed Oct 12 09:14:15 2016 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 4F65F12950F for ; Wed, 12 Oct 2016 09:14:11 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 v4XuUzCHFgYC for ; Wed, 12 Oct 2016 09:14:09 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B165E129595 for ; Wed, 12 Oct 2016 09:14:09 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 12 Oct 2016 09:14:08 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BD5F5BF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BD5F615@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Wed, 12 Oct 2016 09:14:06 -0700 To: Christer Holmberg , "ecrit@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Ecrit] Christer's review of draft-ietf-ecrit-ecall-15 (excluding Section 15) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 16:14:11 -0000 Hi Christer, Please see inline. At 6:37 AM +0000 10/12/16, Christer Holmberg wrote: > Hi, > > Please see inline: > > >>> Q3: >>> >>> In Section 2, the text says: >>> >>> "The technical contents of this document also provide a basis for >>> reuse and extension for other vehicle-initiated emergency call >>> Systems. >>> >>> Vehicles designed for multiple regions might need to support eCall >>> and other Advanced Automatic Crash Notification (AACN) systems, such >>> as described in [I-D.ietf-ecrit-car-crash]." >>> >>> I don't think the text is needed, but if you want to keep it you >>> should explicitly say that it's outside the scope of the document. >> >>I think the first sentence helps explain the expansion items (e.g., >>used by the car-crash draft), and the second was added by request of >>Keith a year or two ago; I'm happy to reword both sentences to make >>it more clear that this is background info. > > > I just want to make it clear that none of the above is something that is > covered in THIS document. OK, I'll make this more clear. > >> Q5: >>> >>> In Section 5, I suggest to re-name the title to "MSD Format", or >>> something like that. >> >>What is your concern with the current title? To me, "Vehicle Data" >>is more general and hence easier to understand for someone who >>doesn't know what an MSD is. The text explains that the data is >>called an MSD. How about if I add "(MSD)" to the title? That way, >>someone who knows they are looking for the MSD info can find it, and >>someone who doesn't know what an MSD is will know what the section is >>about. > > I was thinking more about this, and I'm ok with the current title. > > >>> Q6: >>> >>> In Section 6, please add references to the different SIP/MIME >>> header fields (Content-Type, Content-ID etc). >> >>We have multiple references to RFC 7852. Do you think we need to >>also reference RFC 3261 for Call-Info and RFC 2045 and/or RFC 2392 >>for Content-ID and RFC 2045 for Content-Type and Content-Disposition? > > > I think it would be good to have a reference on first occurrence, > especially since some header fields aren't SIP header fields. These are standard MIME header fields, just as multipart handling is standard MIME, and we don't need a reference to multipart handling. > >> Q7: >>> >>> In Section 6, the text says: >>> >>> "An MSD or a metadata/control block is always enclosed in a >>>multipart >>> body part (even if it would otherwise be the only body part in the >>> SIP message)." >>> >>> We did agree on this for INFO, but is there a reason for doing this >>> also in non-INFO requests? >> >>I suspect so, and it's the same reason: so that Content-ID is valid. >>(In reality, I can't imagine that an MSD would be the only body part >>in an initial INVITE, but I think we need to say so just in case.) > > > You are right. > > Maybe it would be good to add a note saying that the reason is that, at > the time of writing the document, the usage of Content-ID as a SIP header > field was not defined. OK, I'll note that. > > I DO agree that, in most cases, MSD will not be the only body part in the > INVITE. > > >>> Q8: >>> >>> In Section 6, the text says: >>> >>> "Note that in some cases there might be intermediate >>> multipart body parts between the top level multipart and the body >>> part containing the MSD or metadata/control object." >>> >>> I have no idea what that text means. >> >>It's just trying to note that there might be multiple levels of >>multipart. I'll reword this to make it simpler. > > I don't think we need to say anything. It's basic multipart handling, and > we don't define any procedures that mandates multiple levels, so... OK, I'll delete it. > >> Q10: >>> >>> In Section 9, the text says: >>> >>> "if the IVS sends a requested MSD in an INFO request and does > >> not receive a SIP >>> status message for the INFO request, it resends it; if the PSAP >>> requests an MSD and does not receive a SIP status message for the >>> INFO request, it resends it.)" >>> >>> This is basic SIP, and can be removed. Earlier you mention SIP >>> re-transmission, and that's enough. I think you should add the >>> following, though: >>> >>> "Note that, per RFC6086, a 200 OK response to the INFO request >>> only indicates that the receiver has successfully received and >>> accepted the INFO request." >> > >I'm happy to delete the text after "Normal SIP retransmission handles >>non-receipt of requested data". I agree it isn't needed. >> >>Is there specific text that you think is potentially confusing and >>hence needs the note about the semantics of a 200 OK? > > Some may think that 200 OK means that the ecall application accepted the > MSD. We already talk about what the MSD ack means. Let me think about how to work something about what a 200 OK doesn't mean in to that text. > > MSD only means that the receiving SIP stack accepted the INFO. > > >>> Q11: >>> >>> In Section 9, the text says: >>> >>> "The SIP response codes 600 (Busy Everywhere), 486 (Busy Here), >>> and 603 (Decline) are used when >>> the PSAP wants to reject a call but inform the vehicle occupants >>>that >>> it is aware of the situation." >>> >>> Please add a reference to where this is defined. >> >>I'll reword this text. > > My question was not about the wording - it was more about where this is > defined. > > I.e., is this something you define for ecall, or it is something generic > defined elsewhere? It's defined here. I'll reword it to make this more clear (e.g., "a PSAP is able to reject a call but inform...") > >> Q12: >>> >>> In Section 10.6, please add explicit text that says that multipart >>> is used even if only a single body part is transported. >> >>I'll add text to make it more explicit. >> >>> You may even reference the example in RFC 6086. Also add explicit >>> text saying that "Per RFC 6086, the content disposition value of >>> the multipart MIME is 'info-package', or something like that. >> >>We had an email discussion about this some weeks back, and Paul >>pointed out that it wasn't always correct for the top level multipart >>to have a Content-Disposition of INFO-Package. > > The C-D of the multipart which contains the ecall body part(s) shall be > info-package. If a multipart contains only eCall body parts, then maybe so, but as Paul pointed out, a multipart within an INFO request can contain body parts related to the INFO package and other body parts. I think Paul made a larger point that the C-D of multiparts is not straightforward, so it's better not to make a blanket statement about it. > > Perhaps that multipart is within another multipart, but that's a separate > issue. > > >>> Q14: >>> >>> In Section 11, you should add the Content-Disposition SIP header >>> field (with 'info-package' value) to the INFO requests. >> >>In the email discussion, Paul said it was better to leave it off. > > I don't agree. These specific examples are cases where the INFO only > contains ecall information, which is the normal case. I'm happy either way (to add the "Content-Disposition: INFO-package" or leave it off as Paul suggested), but I'd like to hear from Paul before making a change. > > If people also want to add an example where the INFO also contains > non-ecall stuff, we can do that, even though I don't think it's needed. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Justice is incidental to law and order. --J.Edgar Hoover From nobody Wed Oct 12 10:32:45 2016 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 1D2D112947B for ; Wed, 12 Oct 2016 10:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 bkBygR7LCIoH for ; Wed, 12 Oct 2016 10:32:41 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 97DFE1293E0 for ; Wed, 12 Oct 2016 10:32:41 -0700 (PDT) X-AuditID: c1b4fb30-b73ff70000000cb2-ca-57fe73b77d88 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id BC.C9.03250.7B37EF75; Wed, 12 Oct 2016 19:32:40 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0319.002; Wed, 12 Oct 2016 19:32:38 +0200 From: Christer Holmberg To: Randall Gellens , "ecrit@ietf.org" Thread-Topic: [Ecrit] Christer's review of draft-ietf-ecrit-ecall-15 (excluding Section 15) Thread-Index: AQHSJKOryoyCCG7J2EO7CqaYdRb5LqClEAnw Date: Wed, 12 Oct 2016 17:32:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BD66463@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BD5F5BF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BD5F615@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbFdV3dH8b9wg9WPWCwaFz1ltVix4QCr xffnXYwOzB5/339g8liy5CeTx9Y7j1kCmKO4bFJSczLLUov07RK4Mk78nstesFO14tzWl8wN jL9kuhg5OSQETCSev3rO1sXIxSEksJ5R4sbvrYwQzhJGiftLp7J2MXJwsAlYSHT/0wYxRQRC JFrec4H0MgtoSFy+3cUGYgsLxEnMmPOZBcQWEYiXOPn6KBOEbSSxZ+IUsBoWAVWJzqVnWUFs XgFfiTdLF7NCrJrOJNF7/C87SIIT6KCvD84yg9iMAmIS30+tYYJYJi5x68l8JoijBSSW7DnP DGGLSrx8/I8VwlaSWHt4OwtEvY7Egt2f2CBsbYllC18zQywWlDg58wnLBEbRWUjGzkLSMgtJ yywkLQsYWVYxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBMbOwS2/DXYwvnzueIhRgINRiYd3 gcbfcCHWxLLiytxDjBIczEoivJsK/oUL8aYkVlalFuXHF5XmpBYfYpTmYFES5zVbeT9cSCA9 sSQ1OzW1ILUIJsvEwSnVwGh9eMn7mqCU/CyxTzndO/Xnal+p3JpzN/SOYcn23eFL+/7M9BP3 7TwdWPnf+9dNcY5tPX/Tpx/5MDVDIWGpw5rkxk2BO52XHdoW8lK6oVLloar3JQ5+pWsTskUO 7d1plhb/LKP595qvUUViyzZVuZ66JaF1TSRZf2ak6K3iqgXHvcpPPHkpeVGJpTgj0VCLuag4 EQDpO2grmQIAAA== Archived-At: Subject: Re: [Ecrit] Christer's review of draft-ietf-ecrit-ecall-15 (excluding Section 15) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 17:32:44 -0000 Hi, >>>> Q6: >>>> >>>> In Section 6, please add references to the different SIP/MIME =20 >>>> header fields (Content-Type, Content-ID etc). >>> >>>We have multiple references to RFC 7852. Do you think we need to also=20 >>>reference RFC 3261 for Call-Info and RFC 2045 and/or RFC 2392 for=20 >>>Content-ID and RFC 2045 for Content-Type and Content-Disposition? >> >> >> I think it would be good to have a reference on first occurrence, =20 >> especially since some header fields aren't SIP header fields. > > These are standard MIME header fields, just as multipart handling is stan= dard MIME, and we don't need a reference to multipart handling. Ok, I don't want to delay the work because of that, so I withdraw the comme= nt. You may get the same comment from the Gen-ART and/or IESG folks, though= . >>>> Q10: >>>> >>>> In Section 9, the text says: >>>> >>>> "if the IVS sends a requested MSD in an INFO request and does >>>> not receive a SIP >>>> status message for the INFO request, it resends it; if the PSAP >>>> requests an MSD and does not receive a SIP status message for the >>>> INFO request, it resends it.)" >>>> >>>> This is basic SIP, and can be removed. Earlier you mention SIP >>>> re-transmission, and that's enough. I think you should add the >>>> following, though: >>>> >>>> "Note that, per RFC6086, a 200 OK response to the INFO request >>>> only indicates that the receiver has successfully received and >>>> accepted the INFO request." >>> >>>I'm happy to delete the text after "Normal SIP retransmission handles >>>non-receipt of requested data". I agree it isn't needed. >>> >>>Is there specific text that you think is potentially confusing and >>>hence needs the note about the semantics of a 200 OK? >> >> Some may think that 200 OK means that the ecall application accepted th= e >> MSD. > > We already talk about what the MSD ack means. Let me think about how=20 > to work something about what a 200 OK doesn't mean in to that text. I think you should say that the 200 OK only means that the receiver accepte= d the INFO, and that any potential application-level error message will com= e in a separate INFO request.=20 >>>> Q11: >>>> >>>> In Section 9, the text says: >>>> >>>> "The SIP response codes 600 (Busy Everywhere), 486 (Busy Here), >>>> and 603 (Decline) are used when the PSAP wants to reject a call= but inform the vehicle occupants >>>> that it is aware of the situation." >>>> >>>> Please add a reference to where this is defined. >>> >>>I'll reword this text. >> >> My question was not about the wording - it was more about where this is >> defined. >> >> I.e., is this something you define for ecall, or it is something generi= c >> defined elsewhere? > > It's defined here. I'll reword it to make this more clear (e.g., "a=20 > PSAP is able to reject a call but inform...") Does it really belong to section 9? Wouldn't e.g., section 7 be more approp= riate? >>>> Q12: >>>> >>>> In Section 10.6, please add explicit text that says that multipart >>>> is used even if only a single body part is transported. >>> >>>I'll add text to make it more explicit. >>> >>>> You may even reference the example in RFC 6086. Also add explicit >>>> text saying that "Per RFC 6086, the content disposition value of >>>> the multipart MIME is 'info-package', or something like that. >>> >>>We had an email discussion about this some weeks back, and Paul >>>pointed out that it wasn't always correct for the top level multipart >>>to have a Content-Disposition of INFO-Package. >> >> The C-D of the multipart which contains the ecall body part(s) shall be >> info-package. > > If a multipart contains only eCall body parts, then maybe so, but as=20 > Paul pointed out, a multipart within an INFO request can contain body=20 > parts related to the INFO package and other body parts. I think Paul=20 > made a larger point that the C-D of multiparts is not=20 > straightforward, so it's better not to make a blanket statement about=20 > it. The Info Package body part(s) always need to be within a Info-Package multi= part. Then, if you also want to include non-Info Package body part(s), you DO nee= d a "multilevel" multipart. Something like: C-T: multipart/MIME ---boundary C-T multipart/MIME C-D info package ---boundary2 ---boundary2--- ---boundary C-T foo C-D bar=20 ---boundary--- And, as the examples show INFOs with Info Package body parts only, there sh= all be a SIP header field C-D:info-package. Regards, Christer From nobody Wed Oct 12 15:41:37 2016 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 1D57B1294D1 for ; Wed, 12 Oct 2016 15:41:37 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 hNmYprR9zhu4 for ; Wed, 12 Oct 2016 15:41:35 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 285F01293FE for ; Wed, 12 Oct 2016 15:41:35 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 12 Oct 2016 15:41:33 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BD66463@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BD5F5BF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BD5F615@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BD66463@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Wed, 12 Oct 2016 15:41:31 -0700 To: Christer Holmberg , "ecrit@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Ecrit] Christer's review of draft-ietf-ecrit-ecall-15 (excluding Section 15) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 22:41:37 -0000 Hi Christer, I've made all the edits, except for the Content-Disposition, which as I mentioned I'm happy to do either way, but based on the earlier discussion with Paul, I'm concerned that the correct C-D value of multiparts isn't straightforward, so a blanket statement might be incorrect. I think we can avoid saying how C-D is to be set in multiparts since we do say multiple times very plainly that everything that is sent in an INFO request is sent per RFC 6086. So I think we can leave that to implementers' interpretation of the relevant RFCs. See below for other resolutions. At 5:32 PM +0000 10/12/16, Christer Holmberg wrote: > Hi, > > >>>>> Q6: >>>>> >>>>> In Section 6, please add references to the different SIP/MIME >>>>> header fields (Content-Type, Content-ID etc). >>>> >>>>We have multiple references to RFC 7852. Do you think we need to also >>>>reference RFC 3261 for Call-Info and RFC 2045 and/or RFC 2392 for >>>>Content-ID and RFC 2045 for Content-Type and Content-Disposition? >>> >>> >>> I think it would be good to have a reference on first occurrence, >>> especially since some header fields aren't SIP header fields. >> >> These are standard MIME header fields, just as multipart handling >> is standard MIME, and we don't need a reference to multipart >> handling. > > Ok, I don't want to delay the work because of that, so I withdraw > the comment. You may get the same comment from the Gen-ART and/or > IESG folks, though. > >>>>> Q10: >>>>> >>>>> In Section 9, the text says: >>>>> >>>>> "if the IVS sends a requested MSD in an INFO request and does >>>>> not receive a SIP >>>>> status message for the INFO request, it resends it; if the PSAP >>>>> requests an MSD and does not receive a SIP status message for the >>>>> INFO request, it resends it.)" >>>>> >>>>> This is basic SIP, and can be removed. Earlier you mention SIP >>>>> re-transmission, and that's enough. I think you should add the >>>>> following, though: >>>>> >>>>> "Note that, per RFC6086, a 200 OK response to the INFO request >>>>> only indicates that the receiver has successfully received and >>>>> accepted the INFO request." >>>> >>>>I'm happy to delete the text after "Normal SIP retransmission handles >>>>non-receipt of requested data". I agree it isn't needed. >>>> >>>>Is there specific text that you think is potentially confusing and >>>>hence needs the note about the semantics of a 200 OK? >>> >>> Some may think that 200 OK means that the ecall application accepted the >>> MSD. >> >> We already talk about what the MSD ack means. Let me think about how >> to work something about what a 200 OK doesn't mean in to that text. > > I think you should say that the 200 OK only means that the receiver > accepted the INFO, and that any potential application-level error > message will come in a separate INFO request. I added text that "per , a 200 OK response to an INFO request indicates only that the receiver has successfully received and accepted the INFO request, it says nothing about the acceptability of the payload". I'd rather not add text about application-level error messages here, because the specific context is a solicited MSD that the PSAP finds unacceptable, and in that case the PSAP isn't expected to send a negative acknowledgement because (a) the PSAP can request a new MSD if it wants, and (b) the IVS wouldn't be expected to take any action if it did, since any resent MSD would almost certainly have the same problem, since it's likely a bug in either the IVS or PSAP. > > >>>>> Q11: >>>>> >>>>> In Section 9, the text says: >>>>> >>>>> "The SIP response codes 600 (Busy Everywhere), 486 (Busy Here), >>>>> and 603 (Decline) are used when the PSAP wants to reject >>>>> a call but inform the vehicle occupants > >>>> that it is aware of the situation." >>>>> >>>>> Please add a reference to where this is defined. >>>> >>>>I'll reword this text. >>> >>> My question was not about the wording - it was more about where this is >>> defined. >>> >>> I.e., is this something you define for ecall, or it is something generic >>> defined elsewhere? >> >> It's defined here. I'll reword it to make this more clear (e.g., "a >> PSAP is able to reject a call but inform...") > > Does it really belong to section 9? Wouldn't e.g., section 7 be > more appropriate? It could go in several sections, including 9, because it's mostly about the metadata/control object, but I moved it to section 6 because it seemed to fit best there in the flow of the text. > >>>> Q12: > >>>> >>>>> In Section 10.6, please add explicit text that says that multipart >>>>> is used even if only a single body part is transported. >>>> >>>>I'll add text to make it more explicit. >>>> >>>>> You may even reference the example in RFC 6086. Also add explicit >>>>> text saying that "Per RFC 6086, the content disposition value of >>>>> the multipart MIME is 'info-package', or something like that. >>>> >>>>We had an email discussion about this some weeks back, and Paul >>>>pointed out that it wasn't always correct for the top level multipart >>>>to have a Content-Disposition of INFO-Package. >>> >>> The C-D of the multipart which contains the ecall body part(s) shall be >>> info-package. >> >> If a multipart contains only eCall body parts, then maybe so, but as >> Paul pointed out, a multipart within an INFO request can contain body >> parts related to the INFO package and other body parts. I think Paul >> made a larger point that the C-D of multiparts is not >> straightforward, so it's better not to make a blanket statement about >> it. > > The Info Package body part(s) always need to be within a > Info-Package multipart. > > Then, if you also want to include non-Info Package body part(s), > you DO need a "multilevel" multipart. > > Something like: > > > C-T: multipart/MIME > ---boundary > C-T multipart/MIME > C-D info package > ---boundary2 > > ---boundary2--- > ---boundary > C-T foo > C-D bar > > ---boundary--- > > And, as the examples show INFOs with Info Package body parts only, > there shall be a SIP header field C-D:info-package. Since this is different than what Paul said in the earlier exchange, I'd like to get confirmation before adding C-D to the examples. Especially because I think if there's any ambiguity, we may be better off leaving C-D out, since the examples say that not all SIP header fields are shown. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Not a shred of evidence exists in favor of the idea that life is serious. --Brendan Gill From nobody Fri Oct 14 10:01:59 2016 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 86C78127077; Fri, 14 Oct 2016 10:01:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147646451751.18604.4638966497289572815.idtracker@ietfa.amsl.com> Date: Fri, 14 Oct 2016 10:01:57 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 17:01:57 -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 of the IETF. Title : Next-Generation Pan-European eCall Authors : Randall Gellens Hannes Tschofenig Filename : draft-ietf-ecrit-ecall-16.txt Pages : 44 Date : 2016-10-14 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of the pan European in- vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles, providing real-time communications and an integrated set of related data. This document also registers MIME Content Types and an Emergency Call Additional Data Block for the eCall vehicle data and metadata/control data, and an INFO package to enable carrying this data in INFO requests. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-ecall-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-16 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 Oct 14 10:02:21 2016 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 398E812986F; Fri, 14 Oct 2016 10:02:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147646453871.18548.7812739569679702499.idtracker@ietfa.amsl.com> Date: Fri, 14 Oct 2016 10:02:18 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-15.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 17:02:19 -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 of the IETF. Title : Next-Generation Vehicle-Initiated Emergency Calls Authors : Randall Gellens Brian Rosen Hannes Tschofenig Filename : draft-ietf-ecrit-car-crash-15.txt Pages : 43 Date : 2016-10-14 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data. This document also registers a MIME Content Type and Emergency Call Additional Data Block for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash) and an INFO package to enable carrying this and related data in INFO requests. An external specification for the data format, contents, and structure are referenced in this document. This document reuses the technical aspects of next-generation pan- European eCall (a mandated and standardized system for emergency calls by in-vehicle systems within Europe and other regions). However, this document specifies a different set of vehicle (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This document is an extension of the eCall document, with the primary differences being that this document makes the MSD data set optional and VEDS mandatory, and adds attribute values to the metadata/control object to permit greater functionality. This document registers a new INFO package (identical to that registered for eCall but with the addition of the VEDS MIME type). This document also describes legacy (circuit-switched) ACN systems and their migration to next-generation emergency calling, to provide background information and context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-15 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 Oct 14 10:06:38 2016 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 AEA0F12953F for ; Fri, 14 Oct 2016 10:06:36 -0700 (PDT) X-Quarantine-ID: <9UgrPXQMBVzN> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 9UgrPXQMBVzN for ; Fri, 14 Oct 2016 10:06:34 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3ED1293DC for ; Fri, 14 Oct 2016 10:06:33 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9) for ; Fri, 14 Oct 2016 10:06:32 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <147646451751.18604.4638966497289572815.idtracker@ietfa.amsl.com> <147646453871.18548.7812739569679702499.idtracker@ietfa.amsl.com> References: <147646451751.18604.4638966497289572815.idtracker@ietfa.amsl.com> <147646453871.18548.7812739569679702499.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Fri, 14 Oct 2016 10:06:30 -0700 To: ecrit@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: [Ecrit] draft-ietf-ecrit-ecall-16.txt and draft-ietf-ecrit-car-crash-15.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 17:06:36 -0000 Hi everyone, These versions address all comments received, with the exception of the Content-Disposition issue Christer raised. --Randall At 10:01 AM -0700 10/14/16, internet-drafts@ietf.org wrote: > 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 of the IETF. > > Title : Next-Generation Pan-European eCall > Authors : Randall Gellens > Hannes Tschofenig > Filename : draft-ietf-ecrit-ecall-16.txt > Pages : 44 > Date : 2016-10-14 > > Abstract: > This document describes how to use IP-based emergency services > mechanisms to support the next generation of the pan European in- > vehicle emergency call service defined under the eSafety initiative > of the European Commission (generally referred to as "eCall"). eCall > is a standardized and mandated system for a special form of emergency > calls placed by vehicles, providing real-time communications and an > integrated set of related data. > > This document also registers MIME Content Types and an Emergency Call > Additional Data Block for the eCall vehicle data and metadata/control > data, and an INFO package to enable carrying this data in INFO > requests. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ecrit-ecall-16 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-16 > > > 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/ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit At 10:02 AM -0700 10/14/16, internet-drafts@ietf.org wrote: > 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 of the IETF. > > Title : Next-Generation Vehicle-Initiated Emergency Calls > Authors : Randall Gellens > Brian Rosen > Hannes Tschofenig > Filename : draft-ietf-ecrit-car-crash-15.txt > Pages : 43 > Date : 2016-10-14 > > Abstract: > This document describes how to use IP-based emergency services > mechanisms to support the next generation of emergency calls placed > by vehicles (automatically in the event of a crash or serious > incident, or manually invoked by a vehicle occupant) and conveying > vehicle, sensor, and location data related to the crash or incident. > Such calls are often referred to as "Automatic Crash Notification" > (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the > case of manual trigger. The "Advanced" qualifier refers to the > ability to carry a richer set of data. > > This document also registers a MIME Content Type and Emergency Call > Additional Data Block for the vehicle, sensor, and location data > (often referred to as "crash data" even though there is not > necessarily a crash) and an INFO package to enable carrying this and > related data in INFO requests. An external specification for the > data format, contents, and structure are referenced in this document. > > This document reuses the technical aspects of next-generation pan- > European eCall (a mandated and standardized system for emergency > calls by in-vehicle systems within Europe and other regions). > However, this document specifies a different set of vehicle (crash) > data, specifically, the Vehicle Emergency Data Set (VEDS) rather than > the eCall Minimum Set of Data (MSD). This document is an extension > of the eCall document, with the primary differences being that this > document makes the MSD data set optional and VEDS mandatory, and adds > attribute values to the metadata/control object to permit greater > functionality. This document registers a new INFO package (identical > to that registered for eCall but with the addition of the VEDS MIME > type). This document also describes legacy (circuit-switched) ACN > systems and their migration to next-generation emergency calling, to > provide background information and context. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-15 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-15 > > > 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/ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Sat Oct 15 08:24:35 2016 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 356591296DE for ; Sat, 15 Oct 2016 08:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 RCpXGHe7RFqi for ; Sat, 15 Oct 2016 08:24:31 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 05EB1129670 for ; Sat, 15 Oct 2016 08:24:31 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id t73so168936838oie.1 for ; Sat, 15 Oct 2016 08:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=esx6AQi0XH9pB65A4PSxb0M7Ftj7Cg3FtegpGj9EU9g=; b=0iseOh5HKZtNYWbcMmEKd11ZapJUzr6UFqCjJxjbXvC7odh91FR607khYTSInRmOb0 76CQfWzEwuctRC7JNXqhLJG7tldvVIkWghNlwguxz5DpCjCM0WBOtRwzsV38kDu/gefR o+PgG4HUSDEy41O0w1wzRlnekHGoT5xpUCHxPDQwmzeM5v2NVyy6GvAIFVlTDGCYiksx aef6Gx+8HYojL8kxkv+3N+If2aeiurD4WJ5gAHMVwuqZFR4TT6uRogJXcEX0owFxZxFA Ie8ti+kpoJuH+g9bttZm+eLoZ1x6uSxa+y9wDrDNKNo0VvF6Y/pkmImD5G+swyttcaHo Tf4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=esx6AQi0XH9pB65A4PSxb0M7Ftj7Cg3FtegpGj9EU9g=; b=bRE2U5FKbIuvQlFVWm6FzuW7tnJrmzOXerfFXMCc7Ri7azrYx7T1O2Bb5EVc1/+h8Q /JOQY7CaAwomX2oDuLYSxdWOAUESivtRVvUrOvCBmIdEJ6K6lIyBm5ZiqTQDr9lGWR1r kiGbOh2lrRLGcie58CSbO5uEdlPiqcvOypsnxYOnRASUqb+zdG69Js9NfBHdu6uGb0ye qUzUK1zjZO3pHgBOux//UQbjymXuTnJqngiH5sbulVTGhv2JAZDYpplRHVfZBd9PJpIo A49MekjNVz2RcZBtUQlpowTV9YlKIjNHpXRSt4zr1uNzhYFs/qWbIzzXL3LUDozm59xj LrFw== X-Gm-Message-State: AA6/9RkJ6YIgTsvKPHW2HbP/0HNC5YeGD5xqWa8CHGRoIx6nszO3i13wE7oMT5QMDXrvzThv5/aCpYNhFvY75g== X-Received: by 10.202.56.212 with SMTP id f203mr10518371oia.51.1476545070297; Sat, 15 Oct 2016 08:24:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.193.136 with HTTP; Sat, 15 Oct 2016 08:24:29 -0700 (PDT) Received: by 10.202.193.136 with HTTP; Sat, 15 Oct 2016 08:24:29 -0700 (PDT) In-Reply-To: References: <147646451751.18604.4638966497289572815.idtracker@ietfa.amsl.com> <147646453871.18548.7812739569679702499.idtracker@ietfa.amsl.com> From: Az Mankin Date: Sat, 15 Oct 2016 11:24:29 -0400 Message-ID: To: Randy Gellens Content-Type: multipart/alternative; boundary=001a113cab2868f8ef053ee8f0c7 Archived-At: Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-16.txt and draft-ietf-ecrit-car-crash-15.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 15:24:34 -0000 --001a113cab2868f8ef053ee8f0c7 Content-Type: text/plain; charset=UTF-8 I'll request IETF LC first thing on Tuesday. Working on the write-up and will share it tonight. Thank you, WG and Randy On Oct 14, 2016 12:06, "Randall Gellens" wrote: > Hi everyone, > > These versions address all comments received, with the exception of the > Content-Disposition issue Christer raised. > > --Randall > > At 10:01 AM -0700 10/14/16, internet-drafts@ietf.org wrote: > > 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 of the IETF. >> >> Title : Next-Generation Pan-European eCall >> Authors : Randall Gellens >> Hannes Tschofenig >> Filename : draft-ietf-ecrit-ecall-16.txt >> Pages : 44 >> Date : 2016-10-14 >> >> Abstract: >> This document describes how to use IP-based emergency services >> mechanisms to support the next generation of the pan European in- >> vehicle emergency call service defined under the eSafety initiative >> of the European Commission (generally referred to as "eCall"). eCall >> is a standardized and mandated system for a special form of emergency >> calls placed by vehicles, providing real-time communications and an >> integrated set of related data. >> >> This document also registers MIME Content Types and an Emergency Call >> Additional Data Block for the eCall vehicle data and metadata/control >> data, and an INFO package to enable carrying this data in INFO >> requests. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-ecrit-ecall-16 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-16 >> >> >> 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/ >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > At 10:02 AM -0700 10/14/16, internet-drafts@ietf.org wrote: > > 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 of the IETF. >> >> Title : Next-Generation Vehicle-Initiated Emergency >> Calls >> Authors : Randall Gellens >> Brian Rosen >> Hannes Tschofenig >> Filename : draft-ietf-ecrit-car-crash-15.txt >> Pages : 43 >> Date : 2016-10-14 >> >> Abstract: >> This document describes how to use IP-based emergency services >> mechanisms to support the next generation of emergency calls placed >> by vehicles (automatically in the event of a crash or serious >> incident, or manually invoked by a vehicle occupant) and conveying >> vehicle, sensor, and location data related to the crash or incident. >> Such calls are often referred to as "Automatic Crash Notification" >> (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the >> case of manual trigger. The "Advanced" qualifier refers to the >> ability to carry a richer set of data. >> >> This document also registers a MIME Content Type and Emergency Call >> Additional Data Block for the vehicle, sensor, and location data >> (often referred to as "crash data" even though there is not >> necessarily a crash) and an INFO package to enable carrying this and >> related data in INFO requests. An external specification for the >> data format, contents, and structure are referenced in this document. >> >> This document reuses the technical aspects of next-generation pan- >> European eCall (a mandated and standardized system for emergency >> calls by in-vehicle systems within Europe and other regions). >> However, this document specifies a different set of vehicle (crash) >> data, specifically, the Vehicle Emergency Data Set (VEDS) rather than >> the eCall Minimum Set of Data (MSD). This document is an extension >> of the eCall document, with the primary differences being that this >> document makes the MSD data set optional and VEDS mandatory, and adds >> attribute values to the metadata/control object to permit greater >> functionality. This document registers a new INFO package (identical >> to that registered for eCall but with the addition of the VEDS MIME >> type). This document also describes legacy (circuit-switched) ACN >> systems and their migration to next-generation emergency calling, to >> provide background information and context. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-15 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-15 >> >> >> 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/ >> >> _______________________________________________ >> 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 > --001a113cab2868f8ef053ee8f0c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'll request IETF LC first thing on Tuesday. Working on = the write-up and will share it tonight.

Thank you, WG and Randy


On Oct 14, 2016 1= 2:06, "Randall Gellens" <rg+ietf@randy.pensive.org> wrote:
=
Hi everyone,

These versions address all comments received, with the exception of the Con= tent-Disposition issue Christer raised.

--Randall

At 10:01 AM -0700 10/14/16, internet-drafts@ietf.org wrote:

=C2=A0A New Internet-Draft is available from the on-line Internet-Drafts di= rectories.
=C2=A0This draft is a work item of the Emergency Context Resolution with In= ternet Technologies of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Next-Generation Pan-European eCall
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : Randall Gellens
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Hannes Tschofenig
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-ecrit-ecall-16.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 44
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-10-14

=C2=A0Abstract:
=C2=A0 =C2=A0 This document describes how to use IP-based emergency service= s
=C2=A0 =C2=A0 mechanisms to support the next generation of the pan European= in-
=C2=A0 =C2=A0 vehicle emergency call service defined under the eSafety init= iative
=C2=A0 =C2=A0 of the European Commission (generally referred to as "eC= all"). eCall
=C2=A0 =C2=A0 is a standardized and mandated system for a special form of e= mergency
=C2=A0 =C2=A0 calls placed by vehicles, providing real-time communications = and an
=C2=A0 =C2=A0 integrated set of related data.

=C2=A0 =C2=A0 This document also registers MIME Content Types and an Emerge= ncy Call
=C2=A0 =C2=A0 Additional Data Block for the eCall vehicle data and metadata= /control
=C2=A0 =C2=A0 data, and an INFO package to enable carrying this data in INF= O
=C2=A0 =C2=A0 requests.


=C2=A0The IETF datatracker status page for this draft is:
=C2=A0https://datatracker.ietf.org/doc/= draft-ietf-ecrit-ecall/

=C2=A0There's also a htmlized version available at:
=C2=A0https://tools.ietf.org/html/draft-ie= tf-ecrit-ecall-16

=C2=A0A diff from the previous version is available at:
=C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-ecall-16


=C2=A0Please note that it may take a couple of minutes from the time of sub= mission
=C2=A0until the htmlized version and diff are available at tools.ietf.org.<= br>
=C2=A0Internet-Drafts are also available by anonymous FTP at:
=C2=A0ftp://ftp.ietf.org/internet-drafts/

=C2=A0_______________________________________________
=C2=A0Ecrit mailing list
=C2=A0Ecrit@ietf.org
=C2=A0https://www.ietf.org/mailman/listinfo/ecrit

At 10:02 AM -0700 10/14/16, internet-drafts@ietf.org wrote:

=C2=A0A New Internet-Draft is available from the on-line Internet-Drafts di= rectories.
=C2=A0This draft is a work item of the Emergency Context Resolution with In= ternet Technologies of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Next-Generation Vehicle-Initiated Emergency Calls
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : Randall Gellens
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Brian Rosen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Hannes Tschofenig
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-ecrit-car-crash-15.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 43
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-10-14

=C2=A0Abstract:
=C2=A0 =C2=A0 This document describes how to use IP-based emergency service= s
=C2=A0 =C2=A0 mechanisms to support the next generation of emergency calls = placed
=C2=A0 =C2=A0 by vehicles (automatically in the event of a crash or serious=
=C2=A0 =C2=A0 incident, or manually invoked by a vehicle occupant) and conv= eying
=C2=A0 =C2=A0 vehicle, sensor, and location data related to the crash or in= cident.
=C2=A0 =C2=A0 Such calls are often referred to as "Automatic Crash Not= ification"
=C2=A0 =C2=A0 (ACN), or "Advanced Automatic Crash Notification" (= AACN), even in the
=C2=A0 =C2=A0 case of manual trigger.=C2=A0 The "Advanced" qualif= ier refers to the
=C2=A0 =C2=A0 ability to carry a richer set of data.

=C2=A0 =C2=A0 This document also registers a MIME Content Type and Emergenc= y Call
=C2=A0 =C2=A0 Additional Data Block for the vehicle, sensor, and location d= ata
=C2=A0 =C2=A0 (often referred to as "crash data" even though ther= e is not
=C2=A0 =C2=A0 necessarily a crash) and an INFO package to enable carrying t= his and
=C2=A0 =C2=A0 related data in INFO requests.=C2=A0 An external specificatio= n for the
=C2=A0 =C2=A0 data format, contents, and structure are referenced in this d= ocument.

=C2=A0 =C2=A0 This document reuses the technical aspects of next-generation= pan-
=C2=A0 =C2=A0 European eCall (a mandated and standardized system for emerge= ncy
=C2=A0 =C2=A0 calls by in-vehicle systems within Europe and other regions).=
=C2=A0 =C2=A0 However, this document specifies a different set of vehicle (= crash)
=C2=A0 =C2=A0 data, specifically, the Vehicle Emergency Data Set (VEDS) rat= her than
=C2=A0 =C2=A0 the eCall Minimum Set of Data (MSD).=C2=A0 This document is a= n extension
=C2=A0 =C2=A0 of the eCall document, with the primary differences being tha= t this
=C2=A0 =C2=A0 document makes the MSD data set optional and VEDS mandatory, = and adds
=C2=A0 =C2=A0 attribute values to the metadata/control object to permit gre= ater
=C2=A0 =C2=A0 functionality.=C2=A0 This document registers a new INFO packa= ge (identical
=C2=A0 =C2=A0 to that registered for eCall but with the addition of the VED= S MIME
=C2=A0 =C2=A0 type).=C2=A0 This document also describes legacy (circuit-swi= tched) ACN
=C2=A0 =C2=A0 systems and their migration to next-generation emergency call= ing, to
=C2=A0 =C2=A0 provide background information and context.


=C2=A0The IETF datatracker status page for this draft is:
=C2=A0https://datatracker.ietf.org/= doc/draft-ietf-ecrit-car-crash/

=C2=A0There's also a htmlized version available at:
=C2=A0https://tools.ietf.org/html/draf= t-ietf-ecrit-car-crash-15

=C2=A0A diff from the previous version is available at:
=C2=A0https://www.ietf.org/rfcdiff?= url2=3Ddraft-ietf-ecrit-car-crash-15


=C2=A0Please note that it may take a couple of minutes from the time of sub= mission
=C2=A0until the htmlized version and diff are available at tools.ietf.org.<= br>
=C2=A0Internet-Drafts are also available by anonymous FTP at:
=C2=A0ftp://ftp.ietf.org/internet-drafts/

=C2=A0_______________________________________________
=C2=A0Ecrit mailing list
=C2=A0Ecrit@ietf.org
=C2=A0https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
--001a113cab2868f8ef053ee8f0c7-- From nobody Sat Oct 15 09:56:37 2016 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 D5F1512952A for ; Sat, 15 Oct 2016 09:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 T2ufPw7Fw_p5 for ; Sat, 15 Oct 2016 09:56:32 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 35EE112951B for ; Sat, 15 Oct 2016 09:56:31 -0700 (PDT) X-AuditID: c1b4fb3a-ab7ff7000000099a-ea-58025fbb9111 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 24.05.02458.BBF52085; Sat, 15 Oct 2016 18:56:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.90]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Sat, 15 Oct 2016 18:56:26 +0200 From: Christer Holmberg To: Az Mankin , Randy Gellens Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-16.txt and draft-ietf-ecrit-car-crash-15.txt Thread-Index: AQHSJvg+9O7xZNRrfUeyqvriOYWBFaCpu4jQ Date: Sat, 15 Oct 2016 16:56:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BD8FC66@ESESSMB209.ericsson.se> References: <147646451751.18604.4638966497289572815.idtracker@ietfa.amsl.com> <147646453871.18548.7812739569679702499.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BD8FC66ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7tO7eeKYIg1NLzS2WTt3JZNG46Cmr xffnXYwOzB47Z91l91iy5CeTx9Y7j1kCmKO4bFJSczLLUov07RK4MiYsOMdasOouY8WTliNs DYwHrjN2MXJwSAiYSLzeINzFyMUhJLCeUeLb1GmsEM5iRol5Dc1gRWwCFhLd/7S7GDk5RAR8 JW5297CB2MwCqhLnGh+zgJQIC0RJzFymCFESLdH2pokRwjaSuN00FaycBah8fsNJJpByXqAx 9zuFIDY1MEk8Wz2RFaSGUyBQYmpTNxOIzSggJvH91BomiFXiEreezAezJQQEJJbsOc8MYYtK vHz8jxXCVpJYsf0SI0R9vsThR/PYQWxeAUGJkzOfsExgFJmFZNQsJGWzkJTNAjqPWUBTYv0u fYgSRYkp3Q/ZIWwNidY5c9mRxRcwsq9iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIy0g1t+ W+1gPPjc8RCjAAejEg+vgixjhBBrYllxZe4hRgkOZiUR3p9RTBFCvCmJlVWpRfnxRaU5qcWH GKU5WJTEec1W3g8XEkhPLEnNTk0tSC2CyTJxcEo1MGrk9eQsvP/nTse8Seq/S08ITpt+16nX /+ivlu2vj3O8W27lofBQ4eyM3RKOU1rXZCSvKTqgpv1Wr8mUZUfsV+7iX9uO5267fvXvui02 20U3vGTjSVh4Qe/QrHz/4y/XPgtlPm8S9DCSSXhVolb/OvcJqvHrPb80TLPefuRMTX/vFssp 9Rs13Z4osRRnJBpqMRcVJwIA6r9vCLACAAA= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-16.txt and draft-ietf-ecrit-car-crash-15.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2016 16:56:35 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BD8FC66ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldlIG5lZWQgdG8gc29sdmUgdGhlIENvbnRlbnQtRGlzcG9zaXRpb24gaXNzdWUgZmly c3QuIElmIHRoZSBpc3N1ZSBpcyB1bmNsZWFyLCBwZXJoYXBzIGl04oCZcyBub3QgZW5vdWdoIHRv IGNvdmVyIGl0IGluIHRoZSBleGFtcGxlIOKAkyBwZXJoYXBzIHdlIG5lZWQgc29tZSBub3JtYXRp dmUgY2xhcmlmaWNhdGlvbiB0ZXh0IHRvby4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJv bTogRWNyaXQgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQXog TWFua2luDQpTZW50OiAxNSBPY3RvYmVyIDIwMTYgMTg6MjQNClRvOiBSYW5keSBHZWxsZW5zIDxy ZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPg0KQ2M6IGVjcml0QGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW0Vjcml0XSBkcmFmdC1pZXRmLWVjcml0LWVjYWxsLTE2LnR4dCBhbmQgZHJhZnQtaWV0Zi1l Y3JpdC1jYXItY3Jhc2gtMTUudHh0DQoNCg0KSSdsbCByZXF1ZXN0IElFVEYgTEMgZmlyc3QgdGhp bmcgb24gVHVlc2RheS4gV29ya2luZyBvbiB0aGUgd3JpdGUtdXAgYW5kIHdpbGwgc2hhcmUgaXQg dG9uaWdodC4NCg0KVGhhbmsgeW91LCBXRyBhbmQgUmFuZHkNCg0KT24gT2N0IDE0LCAyMDE2IDEy OjA2LCAiUmFuZGFsbCBHZWxsZW5zIiA8cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZzxtYWlsdG86 cmclMkJpZXRmQHJhbmR5LnBlbnNpdmUub3JnPj4gd3JvdGU6DQpIaSBldmVyeW9uZSwNCg0KVGhl c2UgdmVyc2lvbnMgYWRkcmVzcyBhbGwgY29tbWVudHMgcmVjZWl2ZWQsIHdpdGggdGhlIGV4Y2Vw dGlvbiBvZiB0aGUgQ29udGVudC1EaXNwb3NpdGlvbiBpc3N1ZSBDaHJpc3RlciByYWlzZWQuDQoN Ci0tUmFuZGFsbA0KDQpBdCAxMDowMSBBTSAtMDcwMCAxMC8xNC8xNiwgaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KIEEgTmV3 IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURy YWZ0cyBkaXJlY3Rvcmllcy4NCiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBFbWVy Z2VuY3kgQ29udGV4dCBSZXNvbHV0aW9uIHdpdGggSW50ZXJuZXQgVGVjaG5vbG9naWVzIG9mIHRo ZSBJRVRGLg0KDQogICAgICAgICBUaXRsZSAgICAgICAgICAgOiBOZXh0LUdlbmVyYXRpb24gUGFu LUV1cm9wZWFuIGVDYWxsDQogICAgICAgICBBdXRob3JzICAgICAgICAgOiBSYW5kYWxsIEdlbGxl bnMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIEhhbm5lcyBUc2Nob2ZlbmlnDQogICAgICAg IEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTYudHh0DQogICAgICAg IFBhZ2VzICAgICAgICAgICA6IDQ0DQogICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTYtMTAt MTQNCg0KIEFic3RyYWN0Og0KICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0byB1c2Ug SVAtYmFzZWQgZW1lcmdlbmN5IHNlcnZpY2VzDQogICAgbWVjaGFuaXNtcyB0byBzdXBwb3J0IHRo ZSBuZXh0IGdlbmVyYXRpb24gb2YgdGhlIHBhbiBFdXJvcGVhbiBpbi0NCiAgICB2ZWhpY2xlIGVt ZXJnZW5jeSBjYWxsIHNlcnZpY2UgZGVmaW5lZCB1bmRlciB0aGUgZVNhZmV0eSBpbml0aWF0aXZl DQogICAgb2YgdGhlIEV1cm9wZWFuIENvbW1pc3Npb24gKGdlbmVyYWxseSByZWZlcnJlZCB0byBh cyAiZUNhbGwiKS4gZUNhbGwNCiAgICBpcyBhIHN0YW5kYXJkaXplZCBhbmQgbWFuZGF0ZWQgc3lz dGVtIGZvciBhIHNwZWNpYWwgZm9ybSBvZiBlbWVyZ2VuY3kNCiAgICBjYWxscyBwbGFjZWQgYnkg dmVoaWNsZXMsIHByb3ZpZGluZyByZWFsLXRpbWUgY29tbXVuaWNhdGlvbnMgYW5kIGFuDQogICAg aW50ZWdyYXRlZCBzZXQgb2YgcmVsYXRlZCBkYXRhLg0KDQogICAgVGhpcyBkb2N1bWVudCBhbHNv IHJlZ2lzdGVycyBNSU1FIENvbnRlbnQgVHlwZXMgYW5kIGFuIEVtZXJnZW5jeSBDYWxsDQogICAg QWRkaXRpb25hbCBEYXRhIEJsb2NrIGZvciB0aGUgZUNhbGwgdmVoaWNsZSBkYXRhIGFuZCBtZXRh ZGF0YS9jb250cm9sDQogICAgZGF0YSwgYW5kIGFuIElORk8gcGFja2FnZSB0byBlbmFibGUgY2Fy cnlpbmcgdGhpcyBkYXRhIGluIElORk8NCiAgICByZXF1ZXN0cy4NCg0KDQogVGhlIElFVEYgZGF0 YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQogaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC8NCg0KIFRoZXJlJ3MgYWxz byBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWVjcml0LWVjYWxsLTE2DQoNCiBBIGRpZmYgZnJvbSB0aGUgcHJl dmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWlldGYtZWNyaXQtZWNhbGwtMTYNCg0KDQogUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbg0KIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KIEludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCiBmdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQogX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCiBFY3JpdCBtYWlsaW5nIGxpc3QNCiBFY3JpdEBpZXRmLm9y ZzxtYWlsdG86RWNyaXRAaWV0Zi5vcmc+DQogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9lY3JpdA0KDQpBdCAxMDowMiBBTSAtMDcwMCAxMC8xNC8xNiwgaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KIEEg TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0 LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBF bWVyZ2VuY3kgQ29udGV4dCBSZXNvbHV0aW9uIHdpdGggSW50ZXJuZXQgVGVjaG5vbG9naWVzIG9m IHRoZSBJRVRGLg0KDQogICAgICAgICBUaXRsZSAgICAgICAgICAgOiBOZXh0LUdlbmVyYXRpb24g VmVoaWNsZS1Jbml0aWF0ZWQgRW1lcmdlbmN5IENhbGxzDQogICAgICAgICBBdXRob3JzICAgICAg ICAgOiBSYW5kYWxsIEdlbGxlbnMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIEJyaWFuIFJv c2VuDQogICAgICAgICAgICAgICAgICAgICAgICAgICBIYW5uZXMgVHNjaG9mZW5pZw0KICAgICAg ICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWVjcml0LWNhci1jcmFzaC0xNS50eHQNCiAg ICAgICAgUGFnZXMgICAgICAgICAgIDogNDMNCiAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAx Ni0xMC0xNA0KDQogQWJzdHJhY3Q6DQogICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IHRv IHVzZSBJUC1iYXNlZCBlbWVyZ2VuY3kgc2VydmljZXMNCiAgICBtZWNoYW5pc21zIHRvIHN1cHBv cnQgdGhlIG5leHQgZ2VuZXJhdGlvbiBvZiBlbWVyZ2VuY3kgY2FsbHMgcGxhY2VkDQogICAgYnkg dmVoaWNsZXMgKGF1dG9tYXRpY2FsbHkgaW4gdGhlIGV2ZW50IG9mIGEgY3Jhc2ggb3Igc2VyaW91 cw0KICAgIGluY2lkZW50LCBvciBtYW51YWxseSBpbnZva2VkIGJ5IGEgdmVoaWNsZSBvY2N1cGFu dCkgYW5kIGNvbnZleWluZw0KICAgIHZlaGljbGUsIHNlbnNvciwgYW5kIGxvY2F0aW9uIGRhdGEg cmVsYXRlZCB0byB0aGUgY3Jhc2ggb3IgaW5jaWRlbnQuDQogICAgU3VjaCBjYWxscyBhcmUgb2Z0 ZW4gcmVmZXJyZWQgdG8gYXMgIkF1dG9tYXRpYyBDcmFzaCBOb3RpZmljYXRpb24iDQogICAgKEFD TiksIG9yICJBZHZhbmNlZCBBdXRvbWF0aWMgQ3Jhc2ggTm90aWZpY2F0aW9uIiAoQUFDTiksIGV2 ZW4gaW4gdGhlDQogICAgY2FzZSBvZiBtYW51YWwgdHJpZ2dlci4gIFRoZSAiQWR2YW5jZWQiIHF1 YWxpZmllciByZWZlcnMgdG8gdGhlDQogICAgYWJpbGl0eSB0byBjYXJyeSBhIHJpY2hlciBzZXQg b2YgZGF0YS4NCg0KICAgIFRoaXMgZG9jdW1lbnQgYWxzbyByZWdpc3RlcnMgYSBNSU1FIENvbnRl bnQgVHlwZSBhbmQgRW1lcmdlbmN5IENhbGwNCiAgICBBZGRpdGlvbmFsIERhdGEgQmxvY2sgZm9y IHRoZSB2ZWhpY2xlLCBzZW5zb3IsIGFuZCBsb2NhdGlvbiBkYXRhDQogICAgKG9mdGVuIHJlZmVy cmVkIHRvIGFzICJjcmFzaCBkYXRhIiBldmVuIHRob3VnaCB0aGVyZSBpcyBub3QNCiAgICBuZWNl c3NhcmlseSBhIGNyYXNoKSBhbmQgYW4gSU5GTyBwYWNrYWdlIHRvIGVuYWJsZSBjYXJyeWluZyB0 aGlzIGFuZA0KICAgIHJlbGF0ZWQgZGF0YSBpbiBJTkZPIHJlcXVlc3RzLiAgQW4gZXh0ZXJuYWwg c3BlY2lmaWNhdGlvbiBmb3IgdGhlDQogICAgZGF0YSBmb3JtYXQsIGNvbnRlbnRzLCBhbmQgc3Ry dWN0dXJlIGFyZSByZWZlcmVuY2VkIGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgICBUaGlzIGRvY3Vt ZW50IHJldXNlcyB0aGUgdGVjaG5pY2FsIGFzcGVjdHMgb2YgbmV4dC1nZW5lcmF0aW9uIHBhbi0N CiAgICBFdXJvcGVhbiBlQ2FsbCAoYSBtYW5kYXRlZCBhbmQgc3RhbmRhcmRpemVkIHN5c3RlbSBm b3IgZW1lcmdlbmN5DQogICAgY2FsbHMgYnkgaW4tdmVoaWNsZSBzeXN0ZW1zIHdpdGhpbiBFdXJv cGUgYW5kIG90aGVyIHJlZ2lvbnMpLg0KICAgIEhvd2V2ZXIsIHRoaXMgZG9jdW1lbnQgc3BlY2lm aWVzIGEgZGlmZmVyZW50IHNldCBvZiB2ZWhpY2xlIChjcmFzaCkNCiAgICBkYXRhLCBzcGVjaWZp Y2FsbHksIHRoZSBWZWhpY2xlIEVtZXJnZW5jeSBEYXRhIFNldCAoVkVEUykgcmF0aGVyIHRoYW4N CiAgICB0aGUgZUNhbGwgTWluaW11bSBTZXQgb2YgRGF0YSAoTVNEKS4gIFRoaXMgZG9jdW1lbnQg aXMgYW4gZXh0ZW5zaW9uDQogICAgb2YgdGhlIGVDYWxsIGRvY3VtZW50LCB3aXRoIHRoZSBwcmlt YXJ5IGRpZmZlcmVuY2VzIGJlaW5nIHRoYXQgdGhpcw0KICAgIGRvY3VtZW50IG1ha2VzIHRoZSBN U0QgZGF0YSBzZXQgb3B0aW9uYWwgYW5kIFZFRFMgbWFuZGF0b3J5LCBhbmQgYWRkcw0KICAgIGF0 dHJpYnV0ZSB2YWx1ZXMgdG8gdGhlIG1ldGFkYXRhL2NvbnRyb2wgb2JqZWN0IHRvIHBlcm1pdCBn cmVhdGVyDQogICAgZnVuY3Rpb25hbGl0eS4gIFRoaXMgZG9jdW1lbnQgcmVnaXN0ZXJzIGEgbmV3 IElORk8gcGFja2FnZSAoaWRlbnRpY2FsDQogICAgdG8gdGhhdCByZWdpc3RlcmVkIGZvciBlQ2Fs bCBidXQgd2l0aCB0aGUgYWRkaXRpb24gb2YgdGhlIFZFRFMgTUlNRQ0KICAgIHR5cGUpLiAgVGhp cyBkb2N1bWVudCBhbHNvIGRlc2NyaWJlcyBsZWdhY3kgKGNpcmN1aXQtc3dpdGNoZWQpIEFDTg0K ICAgIHN5c3RlbXMgYW5kIHRoZWlyIG1pZ3JhdGlvbiB0byBuZXh0LWdlbmVyYXRpb24gZW1lcmdl bmN5IGNhbGxpbmcsIHRvDQogICAgcHJvdmlkZSBiYWNrZ3JvdW5kIGluZm9ybWF0aW9uIGFuZCBj b250ZXh0Lg0KDQoNCiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBk cmFmdCBpczoNCiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWVj cml0LWNhci1jcmFzaC8NCg0KIFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxh YmxlIGF0Og0KIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWVjcml0LWNh ci1jcmFzaC0xNQ0KDQogQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxh YmxlIGF0Og0KIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWVj cml0LWNhci1jcmFzaC0xNQ0KDQoNCiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQogdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxo dHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQogSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWls YWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KIGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvDQoNCiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KIEVjcml0IG1haWxpbmcgbGlzdA0KIEVjcml0QGlldGYub3JnPG1haWx0bzpFY3JpdEBpZXRm Lm9yZz4NCiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFY3JpdCBtYWls aW5nIGxpc3QNCkVjcml0QGlldGYub3JnPG1haWx0bzpFY3JpdEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg== --_000_7594FB04B1934943A5C02806D1A2204B4BD8FC66ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5XZSBuZWVkIHRvIHNvbHZlIHRoZSBDb250ZW50LURpc3Bvc2l0aW9uIGlzc3VlIGZpcnN0LiBJ ZiB0aGUgaXNzdWUgaXMgdW5jbGVhciwgcGVyaGFwcyBpdOKAmXMgbm90IGVub3VnaCB0byBjb3Zl ciBpdCBpbiB0aGUgZXhhbXBsZSDigJMNCiBwZXJoYXBzIHdlIG5lZWQgc29tZSBub3JtYXRpdmUg Y2xhcmlmaWNhdGlvbiB0ZXh0IHRvby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5D aHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5h bWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEVjcml0IFttYWlsdG86 ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QXogTWFua2luPGJy Pg0KPGI+U2VudDo8L2I+IDE1IE9jdG9iZXIgMjAxNiAxODoyNDxicj4NCjxiPlRvOjwvYj4gUmFu ZHkgR2VsbGVucyAmbHQ7cmcmIzQzO2lldGZAcmFuZHkucGVuc2l2ZS5vcmcmZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiBlY3JpdEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0Vjcml0XSBk cmFmdC1pZXRmLWVjcml0LWVjYWxsLTE2LnR4dCBhbmQgZHJhZnQtaWV0Zi1lY3JpdC1jYXItY3Jh c2gtMTUudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cD5JJ2xsIHJlcXVlc3QgSUVURiBMQyBmaXJzdCB0aGluZyBv biBUdWVzZGF5LiBXb3JraW5nIG9uIHRoZSB3cml0ZS11cCBhbmQgd2lsbCBzaGFyZSBpdCB0b25p Z2h0LjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhhbmsgeW91LCBXRyBhbmQgUmFuZHk8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBPY3QgMTQsIDIwMTYgMTI6MDYsICZxdW90 O1JhbmRhbGwgR2VsbGVucyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJnJTJCaWV0ZkByYW5k eS5wZW5zaXZlLm9yZyI+cmcmIzQzO2lldGZAcmFuZHkucGVuc2l2ZS5vcmc8L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij5IaSBldmVyeW9uZSw8YnI+DQo8YnI+DQpUaGVzZSB2ZXJzaW9ucyBhZGRyZXNzIGFsbCBj b21tZW50cyByZWNlaXZlZCwgd2l0aCB0aGUgZXhjZXB0aW9uIG9mIHRoZSBDb250ZW50LURpc3Bv c2l0aW9uIGlzc3VlIENocmlzdGVyIHJhaXNlZC48YnI+DQo8YnI+DQotLVJhbmRhbGw8YnI+DQo8 YnI+DQpBdCAxMDowMSBBTSAtMDcwMCAxMC8xNC8xNiwgPGEgaHJlZj0ibWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNt O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7QSBOZXcg SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh ZnRzIGRpcmVjdG9yaWVzLjxicj4NCiZuYnNwO1RoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2Yg dGhlIEVtZXJnZW5jeSBDb250ZXh0IFJlc29sdXRpb24gd2l0aCBJbnRlcm5ldCBUZWNobm9sb2dp ZXMgb2YgdGhlIElFVEYuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO1RpdGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IE5leHQt R2VuZXJhdGlvbiBQYW4tRXVyb3BlYW4gZUNhbGw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7QXV0aG9ycyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IFJh bmRhbGwgR2VsbGVuczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtIYW5uZXMgVHNjaG9mZW5pZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxl bmFtZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IGRyYWZ0LWlldGYtZWNyaXQtZWNhbGwt MTYudHh0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBhZ2VzJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDQ0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IERhdGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6 IDIwMTYtMTAtMTQ8YnI+DQo8YnI+DQombmJzcDtBYnN0cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7 IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0byB1c2UgSVAtYmFzZWQgZW1lcmdlbmN5IHNl cnZpY2VzPGJyPg0KJm5ic3A7ICZuYnNwOyBtZWNoYW5pc21zIHRvIHN1cHBvcnQgdGhlIG5leHQg Z2VuZXJhdGlvbiBvZiB0aGUgcGFuIEV1cm9wZWFuIGluLTxicj4NCiZuYnNwOyAmbmJzcDsgdmVo aWNsZSBlbWVyZ2VuY3kgY2FsbCBzZXJ2aWNlIGRlZmluZWQgdW5kZXIgdGhlIGVTYWZldHkgaW5p dGlhdGl2ZTxicj4NCiZuYnNwOyAmbmJzcDsgb2YgdGhlIEV1cm9wZWFuIENvbW1pc3Npb24gKGdl bmVyYWxseSByZWZlcnJlZCB0byBhcyAmcXVvdDtlQ2FsbCZxdW90OykuIGVDYWxsPGJyPg0KJm5i c3A7ICZuYnNwOyBpcyBhIHN0YW5kYXJkaXplZCBhbmQgbWFuZGF0ZWQgc3lzdGVtIGZvciBhIHNw ZWNpYWwgZm9ybSBvZiBlbWVyZ2VuY3k8YnI+DQombmJzcDsgJm5ic3A7IGNhbGxzIHBsYWNlZCBi eSB2ZWhpY2xlcywgcHJvdmlkaW5nIHJlYWwtdGltZSBjb21tdW5pY2F0aW9ucyBhbmQgYW48YnI+ DQombmJzcDsgJm5ic3A7IGludGVncmF0ZWQgc2V0IG9mIHJlbGF0ZWQgZGF0YS48YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7IFRoaXMgZG9jdW1lbnQgYWxzbyByZWdpc3RlcnMgTUlNRSBDb250ZW50 IFR5cGVzIGFuZCBhbiBFbWVyZ2VuY3kgQ2FsbDxicj4NCiZuYnNwOyAmbmJzcDsgQWRkaXRpb25h bCBEYXRhIEJsb2NrIGZvciB0aGUgZUNhbGwgdmVoaWNsZSBkYXRhIGFuZCBtZXRhZGF0YS9jb250 cm9sPGJyPg0KJm5ic3A7ICZuYnNwOyBkYXRhLCBhbmQgYW4gSU5GTyBwYWNrYWdlIHRvIGVuYWJs ZSBjYXJyeWluZyB0aGlzIGRhdGEgaW4gSU5GTzxicj4NCiZuYnNwOyAmbmJzcDsgcmVxdWVzdHMu PGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug Zm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC8iIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWVjcml0LWVjYWxsLzwv YT48YnI+DQo8YnI+DQombmJzcDtUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWls YWJsZSBhdDo8YnI+DQombmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xNiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWVjcml0LWVjYWxsLTE2PC9hPjxicj4NCjxicj4NCiZu YnNwO0EgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+ DQombmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1lY3JpdC1lY2FsbC0xNiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWVjcml0LWVjYWxsLTE2PC9hPjxicj4NCjxicj4NCjxi cj4NCiZuYnNwO1BsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQombmJzcDt1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxi cj4NCiZuYnNwO0ludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3Vz IEZUUCBhdDo8YnI+DQombmJzcDs8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzLyIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvPC9hPjxicj4NCjxicj4NCiZuYnNwO19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7RWNyaXQgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7 PGEgaHJlZj0ibWFpbHRvOkVjcml0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+RWNyaXRAaWV0 Zi5vcmc8L2E+PGJyPg0KJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9lY3JpdCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZWNyaXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCkF0 IDEwOjAyIEFNIC0wNzAwIDEwLzE0LzE2LCA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+ IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtBIE5ldyBJbnRlcm5l dC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGly ZWN0b3JpZXMuPGJyPg0KJm5ic3A7VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgRW1l cmdlbmN5IENvbnRleHQgUmVzb2x1dGlvbiB3aXRoIEludGVybmV0IFRlY2hub2xvZ2llcyBvZiB0 aGUgSUVURi48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGl0 bGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogTmV4dC1HZW5lcmF0 aW9uIFZlaGljbGUtSW5pdGlhdGVkIEVtZXJnZW5jeSBDYWxsczxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtBdXRob3JzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzogUmFuZGFsbCBHZWxsZW5zPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO0JyaWFuIFJvc2VuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO0hhbm5lcyBUc2Nob2ZlbmlnPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IEZpbGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQtaWV0Zi1lY3Jp dC1jYXItY3Jhc2gtMTUudHh0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBhZ2Vz Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDQzPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERhdGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyA6IDIwMTYtMTAtMTQ8YnI+DQo8YnI+DQombmJzcDtBYnN0cmFjdDo8YnI+DQom bmJzcDsgJm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0byB1c2UgSVAtYmFzZWQg ZW1lcmdlbmN5IHNlcnZpY2VzPGJyPg0KJm5ic3A7ICZuYnNwOyBtZWNoYW5pc21zIHRvIHN1cHBv cnQgdGhlIG5leHQgZ2VuZXJhdGlvbiBvZiBlbWVyZ2VuY3kgY2FsbHMgcGxhY2VkPGJyPg0KJm5i c3A7ICZuYnNwOyBieSB2ZWhpY2xlcyAoYXV0b21hdGljYWxseSBpbiB0aGUgZXZlbnQgb2YgYSBj cmFzaCBvciBzZXJpb3VzPGJyPg0KJm5ic3A7ICZuYnNwOyBpbmNpZGVudCwgb3IgbWFudWFsbHkg aW52b2tlZCBieSBhIHZlaGljbGUgb2NjdXBhbnQpIGFuZCBjb252ZXlpbmc8YnI+DQombmJzcDsg Jm5ic3A7IHZlaGljbGUsIHNlbnNvciwgYW5kIGxvY2F0aW9uIGRhdGEgcmVsYXRlZCB0byB0aGUg Y3Jhc2ggb3IgaW5jaWRlbnQuPGJyPg0KJm5ic3A7ICZuYnNwOyBTdWNoIGNhbGxzIGFyZSBvZnRl biByZWZlcnJlZCB0byBhcyAmcXVvdDtBdXRvbWF0aWMgQ3Jhc2ggTm90aWZpY2F0aW9uJnF1b3Q7 PGJyPg0KJm5ic3A7ICZuYnNwOyAoQUNOKSwgb3IgJnF1b3Q7QWR2YW5jZWQgQXV0b21hdGljIENy YXNoIE5vdGlmaWNhdGlvbiZxdW90OyAoQUFDTiksIGV2ZW4gaW4gdGhlPGJyPg0KJm5ic3A7ICZu YnNwOyBjYXNlIG9mIG1hbnVhbCB0cmlnZ2VyLiZuYnNwOyBUaGUgJnF1b3Q7QWR2YW5jZWQmcXVv dDsgcXVhbGlmaWVyIHJlZmVycyB0byB0aGU8YnI+DQombmJzcDsgJm5ic3A7IGFiaWxpdHkgdG8g Y2FycnkgYSByaWNoZXIgc2V0IG9mIGRhdGEuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGlz IGRvY3VtZW50IGFsc28gcmVnaXN0ZXJzIGEgTUlNRSBDb250ZW50IFR5cGUgYW5kIEVtZXJnZW5j eSBDYWxsPGJyPg0KJm5ic3A7ICZuYnNwOyBBZGRpdGlvbmFsIERhdGEgQmxvY2sgZm9yIHRoZSB2 ZWhpY2xlLCBzZW5zb3IsIGFuZCBsb2NhdGlvbiBkYXRhPGJyPg0KJm5ic3A7ICZuYnNwOyAob2Z0 ZW4gcmVmZXJyZWQgdG8gYXMgJnF1b3Q7Y3Jhc2ggZGF0YSZxdW90OyBldmVuIHRob3VnaCB0aGVy ZSBpcyBub3Q8YnI+DQombmJzcDsgJm5ic3A7IG5lY2Vzc2FyaWx5IGEgY3Jhc2gpIGFuZCBhbiBJ TkZPIHBhY2thZ2UgdG8gZW5hYmxlIGNhcnJ5aW5nIHRoaXMgYW5kPGJyPg0KJm5ic3A7ICZuYnNw OyByZWxhdGVkIGRhdGEgaW4gSU5GTyByZXF1ZXN0cy4mbmJzcDsgQW4gZXh0ZXJuYWwgc3BlY2lm aWNhdGlvbiBmb3IgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyBkYXRhIGZvcm1hdCwgY29udGVudHMs IGFuZCBzdHJ1Y3R1cmUgYXJlIHJlZmVyZW5jZWQgaW4gdGhpcyBkb2N1bWVudC48YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7IFRoaXMgZG9jdW1lbnQgcmV1c2VzIHRoZSB0ZWNobmljYWwgYXNwZWN0 cyBvZiBuZXh0LWdlbmVyYXRpb24gcGFuLTxicj4NCiZuYnNwOyAmbmJzcDsgRXVyb3BlYW4gZUNh bGwgKGEgbWFuZGF0ZWQgYW5kIHN0YW5kYXJkaXplZCBzeXN0ZW0gZm9yIGVtZXJnZW5jeTxicj4N CiZuYnNwOyAmbmJzcDsgY2FsbHMgYnkgaW4tdmVoaWNsZSBzeXN0ZW1zIHdpdGhpbiBFdXJvcGUg YW5kIG90aGVyIHJlZ2lvbnMpLjxicj4NCiZuYnNwOyAmbmJzcDsgSG93ZXZlciwgdGhpcyBkb2N1 bWVudCBzcGVjaWZpZXMgYSBkaWZmZXJlbnQgc2V0IG9mIHZlaGljbGUgKGNyYXNoKTxicj4NCiZu YnNwOyAmbmJzcDsgZGF0YSwgc3BlY2lmaWNhbGx5LCB0aGUgVmVoaWNsZSBFbWVyZ2VuY3kgRGF0 YSBTZXQgKFZFRFMpIHJhdGhlciB0aGFuPGJyPg0KJm5ic3A7ICZuYnNwOyB0aGUgZUNhbGwgTWlu aW11bSBTZXQgb2YgRGF0YSAoTVNEKS4mbmJzcDsgVGhpcyBkb2N1bWVudCBpcyBhbiBleHRlbnNp b248YnI+DQombmJzcDsgJm5ic3A7IG9mIHRoZSBlQ2FsbCBkb2N1bWVudCwgd2l0aCB0aGUgcHJp bWFyeSBkaWZmZXJlbmNlcyBiZWluZyB0aGF0IHRoaXM8YnI+DQombmJzcDsgJm5ic3A7IGRvY3Vt ZW50IG1ha2VzIHRoZSBNU0QgZGF0YSBzZXQgb3B0aW9uYWwgYW5kIFZFRFMgbWFuZGF0b3J5LCBh bmQgYWRkczxicj4NCiZuYnNwOyAmbmJzcDsgYXR0cmlidXRlIHZhbHVlcyB0byB0aGUgbWV0YWRh dGEvY29udHJvbCBvYmplY3QgdG8gcGVybWl0IGdyZWF0ZXI8YnI+DQombmJzcDsgJm5ic3A7IGZ1 bmN0aW9uYWxpdHkuJm5ic3A7IFRoaXMgZG9jdW1lbnQgcmVnaXN0ZXJzIGEgbmV3IElORk8gcGFj a2FnZSAoaWRlbnRpY2FsPGJyPg0KJm5ic3A7ICZuYnNwOyB0byB0aGF0IHJlZ2lzdGVyZWQgZm9y IGVDYWxsIGJ1dCB3aXRoIHRoZSBhZGRpdGlvbiBvZiB0aGUgVkVEUyBNSU1FPGJyPg0KJm5ic3A7 ICZuYnNwOyB0eXBlKS4mbmJzcDsgVGhpcyBkb2N1bWVudCBhbHNvIGRlc2NyaWJlcyBsZWdhY3kg KGNpcmN1aXQtc3dpdGNoZWQpIEFDTjxicj4NCiZuYnNwOyAmbmJzcDsgc3lzdGVtcyBhbmQgdGhl aXIgbWlncmF0aW9uIHRvIG5leHQtZ2VuZXJhdGlvbiBlbWVyZ2VuY3kgY2FsbGluZywgdG88YnI+ DQombmJzcDsgJm5ic3A7IHByb3ZpZGUgYmFja2dyb3VuZCBpbmZvcm1hdGlvbiBhbmQgY29udGV4 dC48YnI+DQo8YnI+DQo8YnI+DQombmJzcDtUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFn ZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQombmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWVjcml0LWNhci1jcmFzaC8iIHRhcmdldD0iX2Js YW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWVjcml0LWNh ci1jcmFzaC88L2E+PGJyPg0KPGJyPg0KJm5ic3A7VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVy c2lvbiBhdmFpbGFibGUgYXQ6PGJyPg0KJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtZWNyaXQtY2FyLWNyYXNoLTE1IiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZWNyaXQtY2FyLWNyYXNoLTE1 PC9hPjxicj4NCjxicj4NCiZuYnNwO0EgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlz IGF2YWlsYWJsZSBhdDo8YnI+DQombmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1lY3JpdC1jYXItY3Jhc2gtMTUiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1lY3JpdC1jYXIt Y3Jhc2gtMTU8L2E+PGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7UGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxi cj4NCiZuYnNwO3VudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0 b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KJm5ic3A7SW50ZXJuZXQtRHJhZnRzIGFyZSBh bHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCiZuYnNwOzxhIGhyZWY9ImZ0 cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvIiB0YXJnZXQ9Il9ibGFuayI+ZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L2E+PGJyPg0KPGJyPg0KJm5ic3A7X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQombmJzcDtFY3Jp dCBtYWlsaW5nIGxpc3Q8YnI+DQombmJzcDs8YSBocmVmPSJtYWlsdG86RWNyaXRAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5FY3JpdEBpZXRmLm9yZzwvYT48YnI+DQombmJzcDs8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0IiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdDwvYT48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRWNyaXQgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkVjcml0QGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+RWNyaXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B4BD8FC66ESESSMB209erics_-- From nobody Sun Oct 16 09:21:12 2016 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 BED2D129463 for ; Sun, 16 Oct 2016 09:21:10 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 g0w5Tt618ZBS for ; Sun, 16 Oct 2016 09:21:08 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCF8129447 for ; Sun, 16 Oct 2016 09:21:08 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 16 Oct 2016 09:21:07 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BD8FC66@ESESSMB209.ericsson.se> References: <147646451751.18604.4638966497289572815.idtracker@ietfa.amsl.com> <147646453871.18548.7812739569679702499.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BD8FC66@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Sun, 16 Oct 2016 09:21:05 -0700 To: Christer Holmberg , Az Mankin , Paul Kyzivat From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-16.txt and draft-ietf-ecrit-car-crash-15.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 16:21:11 -0000 Hi Christer, In rereading RFC 6086 and RFC 5621, I don't see any clear statement that the Content-Disposition of a top-level multipart within an INFO request should be Info-Package. RFC 6086 says Content-Disposition is optional at the top level of a SIP message, and the examples in RFC 6086 sometimes show no Content-Disposition at the top level. Upon careful rereading, my interpretation is that the innermost multipart that contains only body parts associated with the INFO package perhaps should have a Content-Disposition of Info-Package. If there is only one multipart, then the innermost is also the top level. Therefore, I propose to add the following text: The innermost multipart that contains only body parts associated with the INFO package SHOULD have a Content-Disposition value of Info- Package (if there is only one multipart, then the innermost is also the top level). And add the C-D header to the examples. --Randy At 4:56 PM +0000 10/15/16, Christer Holmberg wrote: > Hi, > > We need to solve the Content-Disposition issue first. If the issue > is unclear, perhaps it's not enough to cover it in the example - > perhaps we need some normative clarification text too. > > Regards, > > Christer > > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Az Mankin > Sent: 15 October 2016 18:24 > To: Randy Gellens > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-16.txt and > draft-ietf-ecrit-car-crash-15.txt > > I'll request IETF LC first thing on Tuesday. Working on the > write-up and will share it tonight. > Thank you, WG and Randy > > On Oct 14, 2016 12:06, "Randall Gellens" > <rg+ietf@randy.pensive.org> > wrote: > > Hi everyone, > > These versions address all comments received, with the exception of > the Content-Disposition issue Christer raised. > > --Randall > > At 10:01 AM -0700 10/14/16, > internet-drafts@ietf.org wrote: > > 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 of the IETF. > > Title : Next-Generation Pan-European eCall > Authors : Randall Gellens > Hannes Tschofenig > Filename : draft-ietf-ecrit-ecall-16.txt > Pages : 44 > Date : 2016-10-14 > > Abstract: > This document describes how to use IP-based emergency services > mechanisms to support the next generation of the pan European in- > vehicle emergency call service defined under the eSafety initiative > of the European Commission (generally referred to as "eCall"). eCall > is a standardized and mandated system for a special form of emergency > calls placed by vehicles, providing real-time communications and an > integrated set of related data. > > This document also registers MIME Content Types and an Emergency Call > Additional Data Block for the eCall vehicle data and metadata/control > data, and an INFO package to enable carrying this data in INFO > requests. > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-ecrit-ecall-16 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-16 > > > 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/ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > At 10:02 AM -0700 10/14/16, > internet-drafts@ietf.org wrote: > > 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 of the IETF. > > Title : Next-Generation Vehicle-Initiated Emergency Calls > Authors : Randall Gellens > Brian Rosen > Hannes Tschofenig > Filename : draft-ietf-ecrit-car-crash-15.txt > Pages : 43 > Date : 2016-10-14 > > Abstract: > This document describes how to use IP-based emergency services > mechanisms to support the next generation of emergency calls placed > by vehicles (automatically in the event of a crash or serious > incident, or manually invoked by a vehicle occupant) and conveying > vehicle, sensor, and location data related to the crash or incident. > Such calls are often referred to as "Automatic Crash Notification" > (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the > case of manual trigger. The "Advanced" qualifier refers to the > ability to carry a richer set of data. > > This document also registers a MIME Content Type and Emergency Call > Additional Data Block for the vehicle, sensor, and location data > (often referred to as "crash data" even though there is not > necessarily a crash) and an INFO package to enable carrying this and > related data in INFO requests. An external specification for the > data format, contents, and structure are referenced in this document. > > This document reuses the technical aspects of next-generation pan- > European eCall (a mandated and standardized system for emergency > calls by in-vehicle systems within Europe and other regions). > However, this document specifies a different set of vehicle (crash) > data, specifically, the Vehicle Emergency Data Set (VEDS) rather than > the eCall Minimum Set of Data (MSD). This document is an extension > of the eCall document, with the primary differences being that this > document makes the MSD data set optional and VEDS mandatory, and adds > attribute values to the metadata/control object to permit greater > functionality. This document registers a new INFO package (identical > to that registered for eCall but with the addition of the VEDS MIME > type). This document also describes legacy (circuit-switched) ACN > systems and their migration to next-generation emergency calling, to > provide background information and context. > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-15 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-15 > > > 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/ > > _______________________________________________ > 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 -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- One of the greatest labor saving inventions of today is tomorrow. - --Vincent T. Foss From nobody Sun Oct 16 10:12:35 2016 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 16236128E18 for ; Sun, 16 Oct 2016 10:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 duMfR-k5AHsh for ; Sun, 16 Oct 2016 10:12:30 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 9FAEB126CD8 for ; Sun, 16 Oct 2016 10:12:30 -0700 (PDT) X-AuditID: c1b4fb25-14bff7000000793b-5e-5803b4f9af37 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id AC.9A.31035.9F4B3085; Sun, 16 Oct 2016 19:12:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.90]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0319.002; Sun, 16 Oct 2016 19:12:25 +0200 From: Christer Holmberg To: Randall Gellens , Az Mankin , Paul Kyzivat Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-16.txt and draft-ietf-ecrit-car-crash-15.txt Thread-Index: AQHSJ8lO4EUJz0ENWk+fi/gl6E0C1KCrS/HA Date: Sun, 16 Oct 2016 17:12:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BD987B5@ESESSMB209.ericsson.se> References: <147646451751.18604.4638966497289572815.idtracker@ietfa.amsl.com> <147646453871.18548.7812739569679702499.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BD8FC66@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7pe6fLcwRBqtfqlssnbqTyaJx0VNW ixUbDrBafH/exejA4vH3/Qcmj52z7rJ7LFnyk8lj653HLAEsUVw2Kak5mWWpRfp2CVwZEz8t ZS6441Ox+8Ui5gbG69ZdjJwcEgImEhPffWfrYuTiEBJYzyix/tZMRghnMaPEm54H7F2MHBxs AhYS3f+0QRpEBMol5m3/zA5iMwuoSpxrfMwCYgsLREtM3viHFaImRqL3xmc2CNtI4vbhdWBx FqD6xkcbwOK8Ar4Sj7q62SF2vWOS+Nu3DmwoJ9BFhx9vYwKxGQXEJL6fWsMEsUxc4taT+UwQ VwtILNlznhnCFpV4+fgfK4StJLFi+yVGiHodiQW7P7FB2NoSyxa+ZoZYLChxcuYTlgmMorOQ jJ2FpGUWkpZZSFoWMLKsYhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAiMqINbfqvuYLz8xvEQ owAHoxIP74NlTBFCrIllxZW5hxglOJiVRHinbWKOEOJNSaysSi3Kjy8qzUktPsQozcGiJM5r tvJ+uJBAemJJanZqakFqEUyWiYNTqoGxIEdFT1OrWfrJBkmdkqUzor5dPMN07GaBl7uYxdzX l2WU51VcWH6nKyk3U0oy6R7/uYu5Tku8uH/49agKav3de2p558F/q1Zant91VDywerZyQsOy m17WyYZ1DXeP5VRUHD9RPWltwxJnF4nLU37Fccavb0i9V8oSPem99qcfDI4qk526za2VWIoz Eg21mIuKEwF9MnlvpAIAAA== Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-16.txt and draft-ietf-ecrit-car-crash-15.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 17:12:34 -0000 Hi Randall, >In rereading RFC 6086 and RFC 5621, I don't see any clear statement that t= he Content-Disposition of a top-level multipart within an INFO request shou= ld be Info-Package. Section 4.3.1 says: "If an INFO request associated with an Info Package contains a message body part, the body part is identified by a Content-Disposition header field "Info-Package" value. The body part can contain a single MIME type, or it can be a multipart [RFC5621] that contains other body parts associated with the Info Package." >RFC 6086 says Content-Disposition is optional at the top level of a SIP me= ssage, and the examples in RFC >6086 sometimes show no Content-Disposition at the top level. Upon careful= rereading, my interpretation is that the innermost multipart that contains= only body parts >associated with the INFO package perhaps should have a Co= ntent-Disposition of Info-Package. If there is only one multipart, then th= e innermost is also the top level. Correct. It's the innermost multipart that contains body parts associated w= ith the INFO package that shall have a Content-Disposition:info-package. And, in the example of draft-ecall, that "innermost multipart" is the only = multipart, so there shall be a SIP level C-D: info-package header field. >Therefore, I propose to add the following text: > > The innermost multipart that contains only body parts associated with > the INFO package SHOULD have a Content-Disposition value of Info- > Package (if there is only one multipart, then the innermost is also > the top level). > > And add the C-D header to the examples. I think it shall be "MUST", because I can't find any text making it optiona= l. Regards, Christer At 4:56 PM +0000 10/15/16, Christer Holmberg wrote: > Hi, > > We need to solve the Content-Disposition issue first. If the issue is=20 > unclear, perhaps it's not enough to cover it in the example - perhaps=20 > we need some normative clarification text too. > > Regards, > > Christer > > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Az Mankin > Sent: 15 October 2016 18:24 > To: Randy Gellens > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-16.txt and=20 > draft-ietf-ecrit-car-crash-15.txt > > I'll request IETF LC first thing on Tuesday. Working on the write-up=20 > and will share it tonight. > Thank you, WG and Randy > > On Oct 14, 2016 12:06, "Randall Gellens"=20 > <rg+ietf@randy.pensive.org> > wrote: > > Hi everyone, > > These versions address all comments received, with the exception of=20 > the Content-Disposition issue Christer raised. > > --Randall > > At 10:01 AM -0700 10/14/16, =20 > internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Emergency Context Resolution with=20 > Internet Technologies of the IETF. > > Title : Next-Generation Pan-European eCall > Authors : Randall Gellens > Hannes Tschofenig > Filename : draft-ietf-ecrit-ecall-16.txt > Pages : 44 > Date : 2016-10-14 > > Abstract: > This document describes how to use IP-based emergency services > mechanisms to support the next generation of the pan European in- > vehicle emergency call service defined under the eSafety initiative > of the European Commission (generally referred to as "eCall"). eCall > is a standardized and mandated system for a special form of emergenc= y > calls placed by vehicles, providing real-time communications and an > integrated set of related data. > > This document also registers MIME Content Types and an Emergency Cal= l > Additional Data Block for the eCall vehicle data and metadata/contro= l > data, and an INFO package to enable carrying this data in INFO > requests. > > > The IETF datatracker status page for this draft is: >=20 > https://data > tracker.ietf.org/doc/draft-ietf-ecrit-ecall/ > > There's also a htmlized version available at: >=20 > https://tools.i > etf.org/html/draft-ietf-ecrit-ecall-16 > > A diff from the previous version is available at: >=20 > https://w > ww.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-ecall-16 > > > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at=20 > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > =20 > ftp://ftp.ietf.org/internet-draft > s/ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org >=20 > https://www.ietf.org/mail > man/listinfo/ecrit > > > At 10:02 AM -0700 10/14/16, =20 > internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Emergency Context Resolution with=20 > Internet Technologies of the IETF. > > Title : Next-Generation Vehicle-Initiated Emergency C= alls > Authors : Randall Gellens > Brian Rosen > Hannes Tschofenig > Filename : draft-ietf-ecrit-car-crash-15.txt > Pages : 43 > Date : 2016-10-14 > > Abstract: > This document describes how to use IP-based emergency services > mechanisms to support the next generation of emergency calls placed > by vehicles (automatically in the event of a crash or serious > incident, or manually invoked by a vehicle occupant) and conveying > vehicle, sensor, and location data related to the crash or incident. > Such calls are often referred to as "Automatic Crash Notification" > (ACN), or "Advanced Automatic Crash Notification" (AACN), even in th= e > case of manual trigger. The "Advanced" qualifier refers to the > ability to carry a richer set of data. > > This document also registers a MIME Content Type and Emergency Call > Additional Data Block for the vehicle, sensor, and location data > (often referred to as "crash data" even though there is not > necessarily a crash) and an INFO package to enable carrying this and > related data in INFO requests. An external specification for the > data format, contents, and structure are referenced in this document= . > > This document reuses the technical aspects of next-generation pan- > European eCall (a mandated and standardized system for emergency > calls by in-vehicle systems within Europe and other regions). > However, this document specifies a different set of vehicle (crash) > data, specifically, the Vehicle Emergency Data Set (VEDS) rather tha= n > the eCall Minimum Set of Data (MSD). This document is an extension > of the eCall document, with the primary differences being that this > document makes the MSD data set optional and VEDS mandatory, and add= s > attribute values to the metadata/control object to permit greater > functionality. This document registers a new INFO package (identica= l > to that registered for eCall but with the addition of the VEDS MIME > type). This document also describes legacy (circuit-switched) ACN > systems and their migration to next-generation emergency calling, to > provide background information and context. > > > The IETF datatracker status page for this draft is: >=20 > https:// > datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ > > There's also a htmlized version available at: >=20 > https://too > ls.ietf.org/html/draft-ietf-ecrit-car-crash-15 > > A diff from the previous version is available at: >=20 > https > ://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-car-crash-15 > > > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at=20 > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > =20 > ftp://ftp.ietf.org/internet-draft > s/ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org >=20 > https://www.ietf.org/mail > man/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org >=20 > https://www.ietf.org/mail > man/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- One of the greatest l= abor saving inventions of today is tomorrow. - --Vincent T. Foss From nobody Sun Oct 16 11:40:08 2016 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 EBA0A129467 for ; Sun, 16 Oct 2016 11:40:06 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 FovYWYVYyucs for ; Sun, 16 Oct 2016 11:40:05 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5F4129473 for ; Sun, 16 Oct 2016 11:40:05 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 16 Oct 2016 11:40:04 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BD987B5@ESESSMB209.ericsson.se> References: <147646451751.18604.4638966497289572815.idtracker@ietfa.amsl.com> <147646453871.18548.7812739569679702499.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BD8FC66@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BD987B5@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Sun, 16 Oct 2016 11:40:02 -0700 To: Christer Holmberg , Az Mankin , Paul Kyzivat From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-16.txt and draft-ietf-ecrit-car-crash-15.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 18:40:07 -0000 Hi Christer, I added the following text: The innermost multipart that contains only body parts associated with the INFO package has a Content-Disposition value of Info-Package (if there is only one multipart, then the innermost is also the top level). I also added Content-Dispositio: Info-Package to the INFO examples. This should clarify C-D. I'll upload the revision as soon as I hear back. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I hate mankind, for I think myself one of the best of them, and I know how bad I am. --Samuel Johnson From nobody Sun Oct 16 12:18:42 2016 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 0DF181294CA for ; Sun, 16 Oct 2016 12:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 qssow67HeOW9 for ; Sun, 16 Oct 2016 12:18:39 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 A879112949F for ; Sun, 16 Oct 2016 12:18:38 -0700 (PDT) X-AuditID: c1b4fb3a-ab7ff7000000099a-0a-5803d28b83d4 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id CF.DE.02458.B82D3085; Sun, 16 Oct 2016 21:18:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.90]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0319.002; Sun, 16 Oct 2016 21:18:35 +0200 From: Christer Holmberg To: Randall Gellens , Az Mankin , Paul Kyzivat Thread-Topic: [Ecrit] draft-ietf-ecrit-ecall-16.txt and draft-ietf-ecrit-car-crash-15.txt Thread-Index: AQHSJ9y3KREKnDPnHUW+BCMjeUM7HaCrc+VA Date: Sun, 16 Oct 2016 19:18:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BD9990A@ESESSMB209.ericsson.se> References: <147646451751.18604.4638966497289572815.idtracker@ietfa.amsl.com> <147646453871.18548.7812739569679702499.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BD8FC66@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BD987B5@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGbHdQLfnEnOEwawZNhZLp+5ksmhc9JTV YsWGA6wW3593MTqwePx9/4HJY+esu+weS5b8ZPLYeucxSwBLFJdNSmpOZllqkb5dAlfGz94V LAXXmSvm/rJqYHzI1MXIySEhYCKx781cNhBbSGA9o8SL05ldjFxA9mJGid7X04GKODjYBCwk uv9pg9SICJRLzNv+mR3EZhZQlTjX+JgFxBYWiJE4unwzE0RNrMTRKWtZIGwjieOf94LZLED1 vw/sZgSxeQV8Jd5s62CH2HuHWeLGfzMQmxPont77y8BqGAXEJL6fWsMEsUtc4taT+VA3C0gs 2XOeGcIWlXj5+B8rhK0ksWL7JUaIeh2JBbs/sUHY2hLLFr5mhtgrKHFy5hOWCYyis5CMnYWk ZRaSlllIWhYwsqxiFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIylg1t+W+1gPPjc8RCjAAej Eg/vg2VMEUKsiWXFlbmHGCU4mJVEeJ+dY44Q4k1JrKxKLcqPLyrNSS0+xCjNwaIkzmu28n64 kEB6YklqdmpqQWoRTJaJg1OqgbHH9tz5sMqGIiX+F/MePJgTHN4RZsD0UeqbutjTdZ0XBK9W RiT4zRWeuPDbrWKlgN9/d33+tu1jrNn81aqPW3ebHQ7hFrzjKStdvGJST7Xvru1P0w/uctrV 9N4qUqJ76b3fjiFORzOc6k4yfl9+2uPqSvPiCf6ih6Qzp2w54Cwrsf1nWbFx90slluKMREMt 5qLiRACldSt8oQIAAA== Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-16.txt and draft-ietf-ecrit-car-crash-15.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 19:18:40 -0000 Hi, >I added the following text: > > The innermost multipart that contains only body parts associated with > the INFO package has a Content-Disposition value of Info-Package (if > there is only one multipart, then the innermost is also the top > level). Do we really need the "(if there in only one multipart..." text? >I also added > > Content-Dispositio: Info-Package > > to the INFO examples. Thanks!=20 Regards, Christer From nobody Sun Oct 16 15:02:53 2016 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 E15F71293EC for ; Sun, 16 Oct 2016 15:02:50 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 gTKM4H3JmKbA for ; Sun, 16 Oct 2016 15:02:49 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 830571293DF for ; Sun, 16 Oct 2016 15:02:49 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 16 Oct 2016 15:02:48 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BD9990A@ESESSMB209.ericsson.se> References: <147646451751.18604.4638966497289572815.idtracker@ietfa.amsl.com> <147646453871.18548.7812739569679702499.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4BD8FC66@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BD987B5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BD9990A@ESESSMB209.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Sun, 16 Oct 2016 15:02:46 -0700 To: Christer Holmberg , Az Mankin , Paul Kyzivat From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-16.txt and draft-ietf-ecrit-car-crash-15.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 22:02:51 -0000 At 7:18 PM +0000 10/16/16, Christer Holmberg wrote: > Hi, > >>I added the following text: >> >> The innermost multipart that contains only body parts associated with >> the INFO package has a Content-Disposition value of Info-Package (if >> there is only one multipart, then the innermost is also the top >> level). > > Do we really need the "(if there in only one multipart..." text? I added it because I thought someone might be confused about "innermost". I'll delete it and upload the revision now. > >>I also added >> >> Content-Dispositio: Info-Package >> >> to the INFO examples. > > Thanks! > > Regards, > > Christer -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Hain't we got all the fools in town on our side? And hain't that a big enough majority in any town? --Mark Twain, _Huckleberry Finn_ From nobody Sun Oct 16 15:11:38 2016 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 A0BF11293DF; Sun, 16 Oct 2016 15:11:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147665589761.25792.10654167976617181383.idtracker@ietfa.amsl.com> Date: Sun, 16 Oct 2016 15:11:37 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-17.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 22:11:37 -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 of the IETF. Title : Next-Generation Pan-European eCall Authors : Randall Gellens Hannes Tschofenig Filename : draft-ietf-ecrit-ecall-17.txt Pages : 45 Date : 2016-10-16 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of the pan European in- vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles, providing real-time communications and an integrated set of related data. This document also registers MIME Content Types and an Emergency Call Additional Data Block for the eCall vehicle data and metadata/control data, and an INFO package to enable carrying this data in INFO requests. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-ecall-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-17 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 Sun Oct 16 15:11:58 2016 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 07E7D12950A; Sun, 16 Oct 2016 15:11:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147665591702.25792.1336799832398354376.idtracker@ietfa.amsl.com> Date: Sun, 16 Oct 2016 15:11:57 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 22:11:57 -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 of the IETF. Title : Next-Generation Vehicle-Initiated Emergency Calls Authors : Randall Gellens Brian Rosen Hannes Tschofenig Filename : draft-ietf-ecrit-car-crash-16.txt Pages : 43 Date : 2016-10-16 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data. This document also registers a MIME Content Type and Emergency Call Additional Data Block for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash) and an INFO package to enable carrying this and related data in INFO requests. An external specification for the data format, contents, and structure are referenced in this document. This document reuses the technical aspects of next-generation pan- European eCall (a mandated and standardized system for emergency calls by in-vehicle systems within Europe and other regions). However, this document specifies a different set of vehicle (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This document is an extension of the eCall document, with the primary differences being that this document makes the MSD data set optional and VEDS mandatory, and adds attribute values to the metadata/control object to permit greater functionality. This document registers a new INFO package (identical to that registered for eCall but with the addition of the VEDS MIME type). This document also describes legacy (circuit-switched) ACN systems and their migration to next-generation emergency calling, to provide background information and context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-16 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 Sun Oct 16 15:18:11 2016 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 E0D3812950A; Sun, 16 Oct 2016 15:18:09 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -0.432 X-Spam-Level: X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.431] 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 cJgwGp_-vFpn; Sun, 16 Oct 2016 15:18:09 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 36EF7129502; Sun, 16 Oct 2016 15:18:09 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 16 Oct 2016 15:18:08 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <147665589761.25792.10654167976617181383.idtracker@ietfa.amsl.com> References: <147665589761.25792.10654167976617181383.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Sun, 16 Oct 2016 15:18:07 -0700 To: internet-drafts@ietf.org, From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] draft-ietf-ecrit-ecall-17 and draft-ietf-ecrit-car-crash-16 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 22:18:10 -0000 These versions address all comments, including the Content-Disposition issue. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Many years ago in a period commonly know as Next Friday Afternoon, there lived a King who was very Gloomy on Tuesday mornings because he was so Sad thinking about how Unhappy he had been on Monday and how completely Mournful he would be on Wednesday.... --Walt Kelly From nobody Sun Oct 16 15:19:50 2016 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 9369712950A for ; Sun, 16 Oct 2016 15:19:48 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] autolearn=unavailable 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 KVZdaUhpvFES for ; Sun, 16 Oct 2016 15:19:48 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id ED6A81294F3 for ; Sun, 16 Oct 2016 15:14:27 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 16 Oct 2016 15:14:27 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <147646451751.18604.4638966497289572815.idtracker@ietfa.amsl.com> <147646453871.18548.7812739569679702499.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Sun, 16 Oct 2016 15:14:24 -0700 To: Az Mankin , Christer Holmberg From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-16.txt and draft-ietf-ecrit-car-crash-15.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 22:19:48 -0000 Thanks, Allison. ecall-17 and car-crash-16 (just uploaded now) address all comments, including the Content-Disposition issue. --Randy At 11:24 AM -0400 10/15/16, Az Mankin wrote: > I'll request IETF LC first thing on Tuesday. Working on the > write-up and will share it tonight. > > Thank you, WG and Randy -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- When you do not know what you are doing, do it neatly. From nobody Sun Oct 16 15:43:22 2016 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 92A9B129510 for ; Sun, 16 Oct 2016 15:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 eR2VjiqFI9FS for ; Sun, 16 Oct 2016 15:43:20 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 23D4F129481 for ; Sun, 16 Oct 2016 15:43:20 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id t73so193919815oie.1 for ; Sun, 16 Oct 2016 15:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L6lLRnueYXvZybntoFBeCBZZK3BZQ8Zr87+cktFCBTU=; b=HEw8oMmWfs3UKSVBPOTim1G0wODQmjdsQg28khjsapcr5CxY7DqYAPBCQoEQ99tiu+ qYbTTOYDoJxrlczTqDQN8BszfIVOisH+IFiqFKVOsFWflKXWmdmSXPLKznxECzELoTVs wTgnsifwvgXT5d5JysQIQ03nYdvv8R1GP5RkaKINrCrpXwBjaBjDBIGyC1tdILW2LUHf bRQpbcQRNHMFSohVnzlmHkCqVxG9F+pgR1Y9MOROkiAwyl9dTHc9W58G00IEU81AixP6 oi9FfULnCbKuNtxTO10cH84FCXJ/dDH3vhHfbXcNJ+CqKAtHViVtWWkaP/9onZjd9zUJ hJ8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=L6lLRnueYXvZybntoFBeCBZZK3BZQ8Zr87+cktFCBTU=; b=mN5NBKdAqmKfcLzHUJBMxXLbau19LvJgjTwL73POfNa5flDFHh6BLdBPaXYYu4gBHs Gj3h1+pwF3kW9dI20zyr00ijjRIlfPpT/Nu3RRSH6eyAWttK1ltE94ODO6kmO8c2zT2/ 78EpaD9fO6P+3abnIYbDa2KUBjqVdYAjwKHE2jOOMfbmo78aXcHibTcECfu5KRVGfFg1 fWO5ISfy30vTy4Mn5SPhOTzcP1ZEkYu7TGkVmKihvIg2SOKPopsOLLPwaxDXuBSaXtXt CYCAVbdFr+SOyYJ0KmOdDGBqJC6fSH+VdYM6bcAN+n/DpR+tu4FSd5dWUJDBrDCfsW4C 6SnQ== X-Gm-Message-State: AA6/9RnUNGu1rVyU0DxBnd+BaY9GUczHzIpHrXiJWoIeNGENn2B1kD5ZZmmLPu8OVlI5P/cjJGR8GVlFf3Y3bw== X-Received: by 10.157.3.77 with SMTP id 71mr11818509otv.49.1476657799412; Sun, 16 Oct 2016 15:43:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.193.136 with HTTP; Sun, 16 Oct 2016 15:43:18 -0700 (PDT) Received: by 10.202.193.136 with HTTP; Sun, 16 Oct 2016 15:43:18 -0700 (PDT) In-Reply-To: References: <147646451751.18604.4638966497289572815.idtracker@ietfa.amsl.com> <147646453871.18548.7812739569679702499.idtracker@ietfa.amsl.com> From: Az Mankin Date: Sun, 16 Oct 2016 17:43:18 -0500 Message-ID: To: Randy Gellens Content-Type: multipart/alternative; boundary=94eb2c033cf696c0d2053f032fde Archived-At: Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-16.txt and draft-ietf-ecrit-car-crash-15.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2016 22:43:21 -0000 --94eb2c033cf696c0d2053f032fde Content-Type: text/plain; charset=UTF-8 Hooray, thank you! On Oct 16, 2016 17:14, "Randall Gellens" wrote: > Thanks, Allison. ecall-17 and car-crash-16 (just uploaded now) address > all comments, including the Content-Disposition issue. > > --Randy > > At 11:24 AM -0400 10/15/16, Az Mankin wrote: > > I'll request IETF LC first thing on Tuesday. Working on the write-up and >> will share it tonight. >> >> Thank you, WG and Randy >> > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > When you do not know what you are doing, do it neatly. > --94eb2c033cf696c0d2053f032fde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hooray, thank you!


On Oct 16, 2016 1= 7:14, "Randall Gellens" <rg+ietf@randy.pensive.org> wrote:
=
Thanks, Allison.=C2=A0 ecall-17 and car-cras= h-16 (just uploaded now) address all comments, including the Content-Dispos= ition issue.

--Randy

At 11:24 AM -0400 10/15/16, Az Mankin wrote:

=C2=A0I'll request IETF LC first thing on Tuesday. Working on the write= -up and will share it tonight.

=C2=A0Thank you, WG and Randy

--
Randall Gellens
Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak= for myself only
-------------- Randomly selected tag: ---------------
When you do not know what you are doing, do it neatly.
--94eb2c033cf696c0d2053f032fde-- From nobody Sun Oct 16 17:49:00 2016 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 90D96129498 for ; Sun, 16 Oct 2016 17:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 EvrMNH1tQOaV for ; Sun, 16 Oct 2016 17:48:56 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 3D26D129483 for ; Sun, 16 Oct 2016 17:48:56 -0700 (PDT) X-AuditID: c1b4fb30-f60a598000000cb2-a8-58041ff5505b Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 1A.A0.03250.5FF14085; Mon, 17 Oct 2016 02:48:54 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.57) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 17 Oct 2016 02:48:52 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pz1EH7Xl9wjupmmT8RdhcnaQqeM7bZmxCpHZsIFyy/Y=; b=ca9Bl71Xm/0AirhYyqr1ABwE7MPJf0xEeb0lQdiPjlJ/DBmdYLb5041dv2TEz75X1EkfwTQjAesBMMT8Lu5iQryq1FDxo4ULu2f5QI04DiryDp1a0MlrSdRlKcUGIqrfgply78Gml5kLX3jSl1OcGTlCgeVzTj+EShs8urE7Yrw= Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) by AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Mon, 17 Oct 2016 00:48:51 +0000 Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com ([10.169.153.136]) by AM5PR0701MB2468.eurprd07.prod.outlook.com ([10.169.153.136]) with mapi id 15.01.0679.006; Mon, 17 Oct 2016 00:48:51 +0000 From: Ivo Sedlacek To: "ecrit@ietf.org" Thread-Topic: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 Thread-Index: AdIlXlB3PYJg7LLPQ8q28XcEleY30wAtUcXwAH7YjIA= Date: Mon, 17 Oct 2016 00:48:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ivo.sedlacek@ericsson.com; x-originating-ip: [219.159.111.182] x-ms-office365-filtering-correlation-id: bdf4f75f-ec2e-4190-7b5c-08d3f6275d2a x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2468; 6:zafHEMOH40Te91iTQZpMY6PJy65qaRgrxdVOTSb4Ocdvc0gG18iB5eJTMwJ/o0++HgJALtKzcCDtyXouJt+RjVPQkBWIV92kBNnpQUWjTl4ySVCK9X14uhQMdY0dX3Zn75VUyekesZUDbAQXotReon/XYORn6oBKc9WZM270O8Lz4VzhSM00kkecwtWvQNFsr/rZzPWjUL2mNrtWkHtdbt1mE/3vzHBe2Ql9p94dSBuXp+fayMV5bOHPlRrB5wDpq0ImuvNsB4seeUf1W1AzEew6E85vhcgIsHyCep+4B2RErc6WFZWm2HIagUBUNILP; 5:PmpYC1mx6845St6Id1QmB19UsK6lXJY3yNJEy5QolbwLhCyVHDy9eBBt5ykfbidgNYiGIx5EQrjNAXUgPA5FpBkTF0TLerWKOKAAk9GDcpkTyK+WrtCQ70hlD3VGbS7shuN3mpaQ4JXvKLxf7+7L4g==; 24:gpt6Rn9F6t+BaszwOruL/jrwa8Wcd6dX/mYGObV45KabFJ0/2568nfA2dug1aOUOF5OTftprZwJ5QxwkpkmrLkfR5rKFK7BsAab+LIVDveU=; 7:HqnlX8ugbIbZ2mZe+SuHQpVesoj2H4bRJx13T+RPnAaVoCnP1Cuy8/ETlbk9CM770NzxqXbv6vepMlJRBxdmCa9RX1/wpkc9EEHMqtu29aRznktYPpUW5r1F8AmtB9HdrU6KjfVsIFbj/xcHfuTXzh7sUQ6AbQo12Ig49Fa9wrl06ciJ59rZ63bVNOvTQjM1keds6H4s32qgqYqKz9Whq0nPuvgt279Gpi0FuFmwbiIVoIQBoWwa1XcllK8zTZ164UwTOE2PzK5Mx+c/6/VuvcTM57Dxmnj3vW+Fw2GY/ChFnQqwumNGd6fU+wT2QnY4TC39B21VAz2DAc9REO5/7aJY5fwAbsSZ+tlYOQ5gFSQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0701MB2468; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AM5PR0701MB2468; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2468; x-forefront-prvs: 0098BA6C6C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(7696004)(81166006)(8676002)(110136003)(2900100001)(3660700001)(81156014)(102836003)(230783001)(2950100002)(76576001)(107886002)(5640700001)(10400500002)(229853001)(50986999)(2351001)(586003)(6116002)(3846002)(1730700003)(3280700002)(76176999)(54356999)(122556002)(305945005)(74316002)(86362001)(5660300001)(7736002)(7846002)(101416001)(2906002)(189998001)(9686002)(105586002)(5002640100001)(19580405001)(66066001)(11100500001)(97736004)(6916009)(92566002)(5890100001)(68736007)(106356001)(87936001)(2501003)(19580395003)(8936002)(77096005)(15975445007)(33656002)(450100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2468; H:AM5PR0701MB2468.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2016 00:48:51.5663 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2468 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUyM2K7pe43eZYIg9ktvBaNi56yOjB6LFny kymAMYrLJiU1J7MstUjfLoErY/vchIJ3ihVvzvazNzAulupi5OSQEDCReDitkb2LkYtDSGA9 o8SVz8+gnBOMEhPvT2IEcVgEepklXqy5ywKRmcsksWT+TxaQfiGBM4wSz+/xgNhsAnoSE7cc YQWxRQRUJTacWckIYgsLWEl8n7KLESJuL/H1+0tmCNtK4s/Z+2A2C1D9xb6/YDN5BRIkrv/Z wQwxfzujxKKVZl2MHBycAokSN14pg4QZBcQkvp9awwRiMwuIS9x6Mp8J4h0BiSV7zjND2KIS Lx//Y4Woj5H43/2ZFSKuLHHmxhd2kJESAr4S048zgbwlIfCJXeLUrLlQczwknp07wARRky8x a5UIRFhLouPILKiSPYwSL64WQNgyEs92rmCBmDOPTaJl6jFWiPNTJZavbYUGg5TE3SudULaM xIs7e1knMGrOQvIChK0jsWD3JzYIW1ti2cLXzLPAoSIocXLmE5YFjCyrGEWLU4uTctONjPRS izKTi4vz8/TyUks2MQKTw8Etvw12ML587niIUYCDUYmH98Eypggh1sSy4srcQ4wSHMxKIrya UiwRQrwpiZVVqUX58UWlOanFhxilOViUxHnNVt4PFxJITyxJzU5NLUgtgskycXBKNTCG7FSv YVyyZlPq1Mvf5ry0zun/v+YVu3PUtuOybOk1PC26UyIenJ0gnf/XfcvLc3eeu98rYDv/b/Px hnkeLJ9nL8o0c5vh4dA548qtF4KJfGyXsqQm9HpaH/uZG1CRvIp/yo/oGctXBU9j3rbx+gXm ohXP3N25OLicZ6T5de2vLVg6Q2GS6QdFJZbijERDLeai4kQAfh4eEAoDAAA= Archived-At: Subject: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 00:48:59 -0000 I identified a few issues: ISSUE 1: section 3 - given that the section 3 contains a lot of information on legac= y eCall in 3GPP, on ETSI requirements on NG-eCall, and CEN documents, I won= der why the section 3 does not refer to 3GPP TS 24.229 (particularly subcla= use 4.7.6) which gives details of requirements on PSAP for usage of eCall i= n mobile environment. ISSUE 2: section 3 - level of technical detail of the last paragraph of section 3 do= es not fit with level of technical detail of the remaining text of section = 3. ISSUE 3: section 4 - add a reference to stage-3 requirements on eCall in 3GPP TS 24.= 229. ISSUE 4: section 4, " This document registers the 'application/ emergencyCallData.eCall.MSD+per' MIME Content-Type to enable the MSD to be carried in SIP." There is no MIME Content-Type registry. "MIME Content-Type" -> "MIME type" Same in other places of the document. ISSUE 6: section 6 - "An MSD or a metadata/control block is always enclosed in a mul= tipart body part (even if it would otherwise be the only body part in the SIP message)." - which multipart MIME type is meant? multipart/mixed or = multipart/alternative or .... ISSUE 7 section 6 - "The IVS then attaches an updated MSD to a SIP INFO request and sends it within the dialog." - what is meant by "attach= ing MSD to SIP INFO request"? ISSUE 8 section 9 - " If the IVS receives a SIP response without the metadata/con= trol block, it indicates that the SIP dialog is not an NG-eCall (e.g., some part of the call is being handled as a legacy call)." - needs to ta= lk about final responses only, as earlier text states "A metadata/control object is not attached to provisional (e.g., 180) responses." ISSUE 9 section 9 - what is "SIP status message"? ISSUE 10 " For example, if a PSAP is unable to accept an eCall (e.g., due to overload or too many calls from the same location), it can reject the INVITE. Since a metadata/control object is also included in the SIP response that rejects the call, the IVS knows if the PSAP received the MSD, and can inform the vehicle occupants that the PSAP successfully received the vehicle location and information but can't talk to the occupants at that time." - this prevents persons in the car = from getting emergency service of the PSAP using other means (e.g. using ci= rcuit switched network). Possibility for DOS attack. ISSUE 11 "The body for an emergencyCallData.eCall.MSD info package is a multipart bo= dy." - which multipart MIME type is meant? multipart/mixed or multipart/alt= ernative or .... ISSUE 12 "Zero or one application/ emergencyCallData.eCall.MSD+per part (containing an MSD) and zero or more application/emergencyCallData.control+xml (containing a metadata/control object) parts are permitted." - this allows INFO with n= o body part at all. If this is intentional, describe when it is supposed to= be used. If this is not intentional, state that at least one of both is pr= esent. ISSUE 13 "Intermediate multipart body parts MAY appear." - what does it mean? Where is "Intermediate mult= ipart body part" defined? ISSUE 14 "while others can be expected to carry an occasional request" - meaning of "occasional" can b= e whatever, it depends on perspective of the user - once per milisecond, on= ce per second, once per minute, once per hour or once per day? ISSUE 15 Figure 8 expects location body by inclusion of Geolocation: but does not show it. ISSUE 16 >From and To in Figure 9 do not fit From and To in Figure 8. ISSUE 17 >From in Figure 10 does not contain tag. ISSUE 18 Accept in Figure 10 is not correct - INFO response is not expected to conta= in body. ISSUE 19 To in Figure 11 does not contain tag. ISSUE 20 examples contain a value of schemaLocation parameter which is not aligned w= ith https://www.w3.org/TR/xmlschema-0/#schemaLocation stating "The schemaLo= cation attribute value consists of one or more pairs of URI references, sep= arated by white space. " xsi:schemaLocation=3D "urn:ietf:params:xml:ns:EmergencyCallData:control" Kind regards Ivo Sedlacek From nobody Mon Oct 17 13:18:53 2016 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 0F6771295A5 for ; Mon, 17 Oct 2016 13:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digitaldatatech.onmicrosoft.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 cwmDiNgR40HI for ; Mon, 17 Oct 2016 13:18:50 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0076.outbound.protection.outlook.com [104.47.33.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43CF1129983 for ; Mon, 17 Oct 2016 13:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digitaldatatech.onmicrosoft.com; s=selector1-ddti-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/Kn+2CsxhEL42F03r32UvCHB/iWc/xvwWXhlEqMZDjE=; b=jfK1SyvJGQYrRCt1P/un7GXmP9a/K4tzThXqvfpuOLydwsDE7UCkd2fhUBer2BxycNY9Pmh0fQy5lJXcXbWqW4NDPh5JtN5EEG10QJq5kALIQSfy0SbdvpkcTxdOQaY/VjUvqtCPz2gPnh/5WjwtpEEL0R11iWqQo0W3pA0HdnA= Received: from MWHPR17MB1071.namprd17.prod.outlook.com (10.173.122.9) by MWHPR17MB1072.namprd17.prod.outlook.com (10.173.122.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Mon, 17 Oct 2016 20:18:46 +0000 Received: from MWHPR17MB1071.namprd17.prod.outlook.com ([10.173.122.9]) by MWHPR17MB1071.namprd17.prod.outlook.com ([10.173.122.9]) with mapi id 15.01.0659.025; Mon, 17 Oct 2016 20:18:46 +0000 From: Dan Banks To: "ecrit@ietf.org" Thread-Topic: draft-ietf-ecrit-similar-location-03 feedback - additional Thread-Index: AdImVs8NPtvfjq8fRFauw1QoYUYzqA== Date: Mon, 17 Oct 2016 20:18:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=DBanks@ddti.net; x-originating-ip: [4.53.197.18] x-ms-office365-filtering-correlation-id: bd0da427-d81f-476d-6238-08d3f6cacc87 x-microsoft-exchange-diagnostics: 1; MWHPR17MB1072; 6:AjZKFAHIgO2g60kEhceKec37uCKS4LDsfnKjQ3W0WV/2dbdPeiq7xgH8tOj0hPtxl3uGycRM/Zd0tcNXJXhg1NmPOBrDxcBv/HZR7xO4gFNQ1zQ5JbotAW9OpRiCxkTWm/tgVbc/Eu+TgHBVvf8KZKSRffrVysQbDWcETuE3nLmCikGrBrNunJg1MLiEr+Ze7okVSb8b/JGzmnfyTh+d6g6fAOI0DU6b18nWoKRuPRI5d9LXA8H8aMASEpGKiKoO3t6N+KAGrSwn0NYQ9swdieymC5xCdM3KwUkugaQZRHCwpKk3fANMdnEXz+GUTgjO; 5:0aZOW2//Cpx8MpJwkqg5UB24qVX73V14kqhspGxbW2cxl5jff9aSaudemA0Bgl20k5Rnl5n6Mzy1GWCyJ+dGyi0J3vTyMP3gaDvQfP3BEP2OGRvRlXZDXxaooqMzxNt0pGNZ/ke+WlBMc05RwIo80w==; 24:MdDtnEkppWrhNWQV/XOC2AmphnYMHH2FWcwtmbQ1pCF5pDiryNzGSNDpBgMe6eofCN8PUh4P5v69RW4lbmk99SJVZnlW774TkyA6cQbBIr8=; 7:0GDfOm62AmKiBt/HLqL7Mq5HJgHp5Gqgud6I/oPxAOel7Mfs3nYA6PV1Z1yOSKg6mog4AL5kO5j6Dmp7MUJLLZsAlBBykFqzXHtkFJweGHtl6nWJrBT+q7bPtNamQZbFMBuNJ7CCTDQ58rDxX6S3QqspOFvAC4hjq4V+fWVFjEjXzehN1VvGA+UfWg8FGGNnlhCZHsN9cT2S8I/yK/Bc4Pnh3ygNOyo2/BSfV/zu/jJyR2pLTvue6wF8tN+hyJ5qLWZZctgfc10TDXbyBOxLvcQ0w53LvWmlP1j49DdUWby8Z170DiRK2QfpgaX3hDMFVs2NTMR6VDB5O5uZEEmqttZZiVQno1CSrzWZwjOpjNI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR17MB1072; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:MWHPR17MB1072; BCL:0; PCL:0; RULEID:; SRVR:MWHPR17MB1072; x-forefront-prvs: 0098BA6C6C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(5660300001)(2906002)(68736007)(9686002)(189998001)(10400500002)(80792005)(8936002)(110136003)(81166006)(81156014)(1730700003)(7846002)(7696004)(8676002)(5640700001)(77096005)(5630700001)(87936001)(3846002)(102836003)(19625215002)(74316002)(586003)(230783001)(2900100001)(790700001)(66066001)(15975445007)(6116002)(4326007)(76576001)(3660700001)(6916009)(3280700002)(5002640100001)(54356999)(2351001)(229853001)(7736002)(101416001)(92566002)(2501003)(16236675004)(50986999)(33656002)(11100500001)(86362001)(97736004)(105586002)(99286002)(106356001)(122556002)(19300405004)(19580395003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR17MB1072; H:MWHPR17MB1071.namprd17.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ddti.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR17MB1071230707C1DFC2AA96FE1DA7D00MWHPR17MB1071namp_" MIME-Version: 1.0 X-OriginatorOrg: ddti.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2016 20:18:45.2272 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4c0f48ba-5f29-44b1-b29c-1aff8251101b X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR17MB1072 Archived-At: Cc: "Rosen, Brian \(Brian.Rosen@neustar.biz\)" Subject: [Ecrit] draft-ietf-ecrit-similar-location-03 feedback - additional X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 20:18:52 -0000 --_000_MWHPR17MB1071230707C1DFC2AA96FE1DA7D00MWHPR17MB1071namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is one thing I would like to add to the feedback which I sent recentl= y on the similar location draft: Section 4 discusses briefly the possibility of the server limiting the numb= er of returned similar locations. Although the current text expresses the = general idea that there may be a few that are the "most likely" to be the c= orrect location, there are also scenarios where many similar locations coul= d all be equally likely, and the server might need to simply cut off the li= st at a reasonable count. In those situations, I believe it would be helpf= ul if the server indicated when such a limit is actually applied. I suggest that an attribute be added to the locationValidation element of t= he findService response, perhaps rli:similarLocationsLimited, having a data= type of boolean, with instructions that a server SHOULD include this attri= bute if the number of returned similar locations is limited due to configur= ation or policy. Dan Banks --_000_MWHPR17MB1071230707C1DFC2AA96FE1DA7D00MWHPR17MB1071namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There is one thing I would like to add to the feedba= ck which I sent recently on the similar location draft:

 

Section 4 discusses briefly the possibility of the s= erver limiting the number of returned similar locations.  Although the= current text expresses the general idea that there may be a few that are t= he “most likely” to be the correct location, there are also scenarios where many similar locations could all be equally= likely, and the server might need to simply cut off the list at a reasonab= le count.  In those situations, I believe it would be helpful if the s= erver indicated when such  a limit is actually applied.

 

I suggest that an attribute be added to the location= Validation element of the findService response, perhaps rli:similarLocation= sLimited, having a data type of boolean, with instructions that a server SH= OULD include this attribute if the number of returned similar locations is limited due to configuration or po= licy.

 

Dan Banks

--_000_MWHPR17MB1071230707C1DFC2AA96FE1DA7D00MWHPR17MB1071namp_-- From nobody Mon Oct 17 13:24:29 2016 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 992D61294CA for ; Mon, 17 Oct 2016 13:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 mwwCApjrAzJi for ; Mon, 17 Oct 2016 13:24:27 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 2AD35129492 for ; Mon, 17 Oct 2016 13:24:27 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9HKNJsG028230; Mon, 17 Oct 2016 16:24:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=neustar-biz; bh=PEtdHoNROd7jsqG1hxXl+CkL0CgKA6dhztFx1pSbSG8=; b=EisL4RttAw1fLDhOR7s57GPgQ3LBbsF3Fh13aCotUm5NLQClhuuvOnYNzgflVSoTKpAD 3u0ifS/Pg961sw4bHXQXS41jQEUImMfjtA+zUtCYZc74tDj7flVfbWsRZ5eSYOnXHrOE h9DsQCARFk6a5q8UiATaDUNNOuGZk9DzJjRBVjTQezo6ODwM9lPVtA4S9rB1NFDOmPik vUuJD0X8IUkNvSP0pN0/LSY96ALWtpIrP5ekzLuVi94HyZ5HBFJ+kZTg5vaMH0cJi0ev zeBEKy9FlTXUG0ezI8m4pL6VSlgHWUdYrxEOGg6B13jr47mAvHF/9CVV73KbI75LEy5m VA== Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 2641a42r2g-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 17 Oct 2016 16:24:25 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Mon, 17 Oct 2016 16:24:23 -0400 From: "Rosen, Brian" To: Dan Banks , "ecrit@ietf.org" Thread-Topic: draft-ietf-ecrit-similar-location-03 feedback - additional Thread-Index: AdImVs8NPtvfjq8fRFauw1QoYUYzqACXaE6A Date: Mon, 17 Oct 2016 20:24:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-originating-ip: [10.33.193.29] Content-Type: multipart/alternative; boundary="_000_D42AAAA2F03E6brianrosenneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-17_08:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-similar-location-03 feedback - additional X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 20:24:28 -0000 --_000_D42AAAA2F03E6brianrosenneustarbiz_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHJlYWxseSBoYXZlIGEgcHJvYmxlbSB3aXRoIGhhdmluZyB0aGlzIG9wdGlvbiwg YnV0IG9uZSBxdWVzdGlvbiBJIGhhdmUgaXMgd2hhdCB3b3VsZCB0aGUgY2xpZW50IGRvIHdpdGgg dGhhdCBpbmZvcm1hdGlvbj8gIEkgY2Fu4oCZdCB0aGluayBvZiBhbnkgYmVoYXZpb3IgY2hhbmdl IHRoYXQgcmV0dXJuIG9mIHRoYXQgaW5mb3JtYXRpb24gd291bGQgdHJpZ2dlci4NCg0KQnJpYW4N Cg0KRnJvbTogRGFuIEJhbmtzIDxEQmFua3NAZGR0aS5uZXQ8bWFpbHRvOkRCYW5rc0BkZHRpLm5l dD4+DQpEYXRlOiBNb25kYXksIE9jdG9iZXIgMTcsIDIwMTYgYXQgNDoxOCBQTQ0KVG86ICJlY3Jp dEBpZXRmLm9yZzxtYWlsdG86ZWNyaXRAaWV0Zi5vcmc+IiA8ZWNyaXRAaWV0Zi5vcmc8bWFpbHRv OmVjcml0QGlldGYub3JnPj4NCkNjOiBCcmlhbiBSb3NlbiA8YnJpYW4ucm9zZW5AbmV1c3Rhci5i aXo8bWFpbHRvOmJyaWFuLnJvc2VuQG5ldXN0YXIuYml6Pj4NClN1YmplY3Q6IGRyYWZ0LWlldGYt ZWNyaXQtc2ltaWxhci1sb2NhdGlvbi0wMyBmZWVkYmFjayAtIGFkZGl0aW9uYWwNCg0KVGhlcmUg aXMgb25lIHRoaW5nIEkgd291bGQgbGlrZSB0byBhZGQgdG8gdGhlIGZlZWRiYWNrIHdoaWNoIEkg c2VudCByZWNlbnRseSBvbiB0aGUgc2ltaWxhciBsb2NhdGlvbiBkcmFmdDoNCg0KU2VjdGlvbiA0 IGRpc2N1c3NlcyBicmllZmx5IHRoZSBwb3NzaWJpbGl0eSBvZiB0aGUgc2VydmVyIGxpbWl0aW5n IHRoZSBudW1iZXIgb2YgcmV0dXJuZWQgc2ltaWxhciBsb2NhdGlvbnMuICBBbHRob3VnaCB0aGUg Y3VycmVudCB0ZXh0IGV4cHJlc3NlcyB0aGUgZ2VuZXJhbCBpZGVhIHRoYXQgdGhlcmUgbWF5IGJl IGEgZmV3IHRoYXQgYXJlIHRoZSDigJxtb3N0IGxpa2VseeKAnSB0byBiZSB0aGUgY29ycmVjdCBs b2NhdGlvbiwgdGhlcmUgYXJlIGFsc28gc2NlbmFyaW9zIHdoZXJlIG1hbnkgc2ltaWxhciBsb2Nh dGlvbnMgY291bGQgYWxsIGJlIGVxdWFsbHkgbGlrZWx5LCBhbmQgdGhlIHNlcnZlciBtaWdodCBu ZWVkIHRvIHNpbXBseSBjdXQgb2ZmIHRoZSBsaXN0IGF0IGEgcmVhc29uYWJsZSBjb3VudC4gIElu IHRob3NlIHNpdHVhdGlvbnMsIEkgYmVsaWV2ZSBpdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHRoZSBz ZXJ2ZXIgaW5kaWNhdGVkIHdoZW4gc3VjaCAgYSBsaW1pdCBpcyBhY3R1YWxseSBhcHBsaWVkLg0K DQpJIHN1Z2dlc3QgdGhhdCBhbiBhdHRyaWJ1dGUgYmUgYWRkZWQgdG8gdGhlIGxvY2F0aW9uVmFs aWRhdGlvbiBlbGVtZW50IG9mIHRoZSBmaW5kU2VydmljZSByZXNwb25zZSwgcGVyaGFwcyBybGk6 c2ltaWxhckxvY2F0aW9uc0xpbWl0ZWQsIGhhdmluZyBhIGRhdGEgdHlwZSBvZiBib29sZWFuLCB3 aXRoIGluc3RydWN0aW9ucyB0aGF0IGEgc2VydmVyIFNIT1VMRCBpbmNsdWRlIHRoaXMgYXR0cmli dXRlIGlmIHRoZSBudW1iZXIgb2YgcmV0dXJuZWQgc2ltaWxhciBsb2NhdGlvbnMgaXMgbGltaXRl ZCBkdWUgdG8gY29uZmlndXJhdGlvbiBvciBwb2xpY3kuDQoNCkRhbiBCYW5rcw0K --_000_D42AAAA2F03E6brianrosenneustarbiz_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5JIGRvbuKAmXQg cmVhbGx5IGhhdmUgYSBwcm9ibGVtIHdpdGggaGF2aW5nIHRoaXMgb3B0aW9uLCBidXQgb25lIHF1 ZXN0aW9uIEkgaGF2ZSBpcyB3aGF0IHdvdWxkIHRoZSBjbGllbnQgZG8gd2l0aCB0aGF0IGluZm9y bWF0aW9uPyAmbmJzcDtJIGNhbuKAmXQgdGhpbmsgb2YgYW55IGJlaGF2aW9yIGNoYW5nZSB0aGF0 IHJldHVybiBvZiB0aGF0IGluZm9ybWF0aW9uIHdvdWxkIHRyaWdnZXIuPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5CcmlhbjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlk PSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp OyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJP VFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RU T006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRP UDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkct VE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5E YW4gQmFua3MgJmx0OzxhIGhyZWY9Im1haWx0bzpEQmFua3NAZGR0aS5uZXQiPkRCYW5rc0BkZHRp Lm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwv c3Bhbj5Nb25kYXksIE9jdG9iZXIgMTcsIDIwMTYgYXQgNDoxOCBQTTxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzplY3Jp dEBpZXRmLm9yZyI+ZWNyaXRAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 ZWNyaXRAaWV0Zi5vcmciPmVjcml0QGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5CcmlhbiBSb3NlbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOmJyaWFuLnJvc2VuQG5ldXN0YXIuYml6Ij5icmlhbi5yb3NlbkBuZXVzdGFyLmJpejwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5k cmFmdC1pZXRmLWVjcml0LXNpbWlsYXItbG9jYXRpb24tMDMgZmVlZGJhY2sgLSBhZGRpdGlvbmFs PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1h cy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpv ZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3 b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEy L29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxtZXRhIG5h bWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1 bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYg bGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBpcyBvbmUgdGhpbmcg SSB3b3VsZCBsaWtlIHRvIGFkZCB0byB0aGUgZmVlZGJhY2sgd2hpY2ggSSBzZW50IHJlY2VudGx5 IG9uIHRoZSBzaW1pbGFyIGxvY2F0aW9uIGRyYWZ0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T ZWN0aW9uIDQgZGlzY3Vzc2VzIGJyaWVmbHkgdGhlIHBvc3NpYmlsaXR5IG9mIHRoZSBzZXJ2ZXIg bGltaXRpbmcgdGhlIG51bWJlciBvZiByZXR1cm5lZCBzaW1pbGFyIGxvY2F0aW9ucy4mbmJzcDsg QWx0aG91Z2ggdGhlIGN1cnJlbnQgdGV4dCBleHByZXNzZXMgdGhlIGdlbmVyYWwgaWRlYSB0aGF0 IHRoZXJlIG1heSBiZSBhIGZldyB0aGF0IGFyZSB0aGUg4oCcbW9zdCBsaWtlbHnigJ0gdG8gYmUg dGhlIGNvcnJlY3QgbG9jYXRpb24sDQogdGhlcmUgYXJlIGFsc28gc2NlbmFyaW9zIHdoZXJlIG1h bnkgc2ltaWxhciBsb2NhdGlvbnMgY291bGQgYWxsIGJlIGVxdWFsbHkgbGlrZWx5LCBhbmQgdGhl IHNlcnZlciBtaWdodCBuZWVkIHRvIHNpbXBseSBjdXQgb2ZmIHRoZSBsaXN0IGF0IGEgcmVhc29u YWJsZSBjb3VudC4mbmJzcDsgSW4gdGhvc2Ugc2l0dWF0aW9ucywgSSBiZWxpZXZlIGl0IHdvdWxk IGJlIGhlbHBmdWwgaWYgdGhlIHNlcnZlciBpbmRpY2F0ZWQgd2hlbiBzdWNoICZuYnNwO2EgbGlt aXQgaXMNCiBhY3R1YWxseSBhcHBsaWVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN1Z2dl c3QgdGhhdCBhbiBhdHRyaWJ1dGUgYmUgYWRkZWQgdG8gdGhlIGxvY2F0aW9uVmFsaWRhdGlvbiBl bGVtZW50IG9mIHRoZSBmaW5kU2VydmljZSByZXNwb25zZSwgcGVyaGFwcyBybGk6c2ltaWxhckxv Y2F0aW9uc0xpbWl0ZWQsIGhhdmluZyBhIGRhdGEgdHlwZSBvZiBib29sZWFuLCB3aXRoIGluc3Ry dWN0aW9ucyB0aGF0IGEgc2VydmVyIFNIT1VMRCBpbmNsdWRlIHRoaXMgYXR0cmlidXRlIGlmIHRo ZQ0KIG51bWJlciBvZiByZXR1cm5lZCBzaW1pbGFyIGxvY2F0aW9ucyBpcyBsaW1pdGVkIGR1ZSB0 byBjb25maWd1cmF0aW9uIG9yIHBvbGljeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGFuIEJh bmtzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_D42AAAA2F03E6brianrosenneustarbiz_-- From nobody Mon Oct 17 14:45:53 2016 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 BC6DC12943F for ; Mon, 17 Oct 2016 14:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digitaldatatech.onmicrosoft.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 bqyUq1tYuXCr for ; Mon, 17 Oct 2016 14:45:49 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0055.outbound.protection.outlook.com [104.47.38.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40B09129439 for ; Mon, 17 Oct 2016 14:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digitaldatatech.onmicrosoft.com; s=selector1-ddti-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Gk5ATZFRIKRvJ6+dOTKAt4F6oOXGOPIIYMOURe+aL3k=; b=jjDl59SMOBM8f1L4FIxCB3qMkxHaFkGYXxLHQ6dy3L1QFwBH5tW2EaHDGzrFD4/exb18j5kQ11J9rMG9hz0AhzzWpe+98HlUG5hdY5GYmvHvMZ/0SYLZH467UJuiqLbpdxWzA2H3NK+mxdvLRK1YukqV1jWnjeA3x4x2qYjAUh8= Received: from MWHPR17MB1071.namprd17.prod.outlook.com (10.173.122.9) by MWHPR17MB1071.namprd17.prod.outlook.com (10.173.122.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Mon, 17 Oct 2016 21:45:46 +0000 Received: from MWHPR17MB1071.namprd17.prod.outlook.com ([10.173.122.9]) by MWHPR17MB1071.namprd17.prod.outlook.com ([10.173.122.9]) with mapi id 15.01.0659.025; Mon, 17 Oct 2016 21:45:46 +0000 From: Dan Banks To: "Rosen, Brian" , "ecrit@ietf.org" Thread-Topic: draft-ietf-ecrit-similar-location-03 feedback - additional Thread-Index: AdImVs8NPtvfjq8fRFauw1QoYUYzqACXaE6AAAHvg2A= Date: Mon, 17 Oct 2016 21:45:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=DBanks@ddti.net; x-originating-ip: [4.53.197.18] x-ms-office365-filtering-correlation-id: 47f599d6-adbc-44e3-d172-08d3f6d6f39e x-microsoft-exchange-diagnostics: 1; MWHPR17MB1071; 6:HI201R/otj0AFGxGAroY/KuTtR+hEL7Q0+tD+LBY1HQ9sUqIheg2Ro66hCQDF1HcfL016w/N4UVXG8FhvqaGNT4Jsu1Wecg0ITaE/b0jbcteiYI/ZnYoMsyYMUchnAGkF9IYmWjZGIf5CeNbPIO+WTble+M0xs6FJnhvzyqsImNAbMojGZ5S6Dmnz498ZqqPGQgf1yZggYfgPtM2tu0dRyi/beSymZiYagXtSNjlAJxlxsnVJgbVrmhIaJRZJzBB9WRhZktgO1zl6d/TMXF7PRMHGZJkpztzghKoLC3Fab6V0Gaml0ZiHaxXqm4K6y5B; 5:DGnPREE5ifRadHCNjIqDtAeg2hZGnhx6SqPWHIfsO4i4ghp+6YKqILDIaj7tpy9qbvGimtAAlDNyEFCJB08qKq3OwHG/9V8aOcSa55QlLFxFzG0/SyVvWGaOOfHYfBgXjrpO+0Meu+oi57OSlLmBGHxt6dFS3Xa9FHem8h6pvFk=; 24:LAa8DAFxlRQJYj8ZKOyvlqDSOR2ji4RkwqkgLOfIyeNb4LUcobx93Ei2nlZnVvJFoY8duvdkDhepIclrZ6s2X6SOu5wIE7hPxJjXI2uUBCA=; 7:Lsi9pdjr7EPd1WV0XeJa8Kz5cDXf4DQ1ms8eVJEUycNDGjD//Irm0Kz9wVcEg7uM3Ga3wbrZdA65i80QC8+NDiNg6nm7oeQikcXySwf12UalDVfVHguC4RnnQlbiozzTa8paRTcS5gc3m+Qh5HhKmt7NRwLfKmgbOjTsu/UGpcSnLg63dsSBkxDJ4ztE61LaGd4wQtV4CigHCRN4mPtrf4cJl2Yo0s5VrJsEGfzC8k39sNJppo37nFO14u6tSUuxECM9Dmsz0JpBA8ydhr3tk3LVZ2+Tu8Lh56GoqME34XfRh+D6fmyvANYYn3z6+5uMWpq1a5Ei50id91u2ikFtnqNwd192bXeuSAwMY5BTRx8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR17MB1071; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:MWHPR17MB1071; BCL:0; PCL:0; RULEID:; SRVR:MWHPR17MB1071; x-forefront-prvs: 0098BA6C6C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(189002)(377454003)(81156014)(5660300001)(66066001)(586003)(76576001)(10400500002)(74316002)(105586002)(99286002)(2900100001)(3280700002)(80792005)(2950100002)(7736002)(7846002)(92566002)(230783001)(19580395003)(68736007)(101416001)(122556002)(2501003)(33656002)(5002640100001)(106356001)(6116002)(102836003)(81166006)(87936001)(11100500001)(189998001)(3846002)(5001770100001)(790700001)(15975445007)(54356999)(107886002)(76176999)(9686002)(2906002)(7696004)(86362001)(50986999)(3660700001)(8936002)(19580405001)(16236675004)(19625215002)(77096005)(19300405004)(97736004)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR17MB1071; H:MWHPR17MB1071.namprd17.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ddti.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR17MB10713730C2A09CD1B0FFC4A9A7D00MWHPR17MB1071namp_" MIME-Version: 1.0 X-OriginatorOrg: ddti.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2016 21:45:45.8376 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4c0f48ba-5f29-44b1-b29c-1aff8251101b X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR17MB1071 Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-similar-location-03 feedback - additional X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 21:45:52 -0000 --_000_MWHPR17MB10713730C2A09CD1B0FFC4A9A7D00MWHPR17MB1071namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gdGhpbmtpbmcgb2YgYW4gZXhhbXBsZSB3aGVyZSB5b3UgbWlnaHQgYSBsYXJnZSBhcGFy dG1lbnQgYnVpbGRpbmcsIGFuZCBhIHF1ZXJ5IHRoYXQgZGlkIG5vdCBpbmNsdWRlIHVuaXQgb3Ig Zmxvb3IuICBJZiB0aGUgcmVzcG9uc2Ugb25seSBsaXN0cyB0aGUgZmlyc3QgNSB1bml0cyBhcyBz aW1pbGFyIGxvY2F0aW9ucywgYSBwZXJzb24gbG9va2luZyBhdCB0aGlzIG1pZ2h0IChpbmNvcnJl Y3RseSkgYXNzdW1lIHRoYXQgdGhlIHNlcnZlciBkb2VzbuKAmXQgaGF2ZSBkYXRhIGZvciB0aGUg b3RoZXIgMTMgdW5pdHMgaW4gdGhhdCBidWlsZGluZy4gIE9mIGNvdXJzZSwgdGhlcmUgaXMgYWxy ZWFkeSBhIGdvb2QgZGlzY2xhaW1lciBpbiB0aGUgZHJhZnQgbm90IHRvIG1ha2Ugc3VjaCBhc3N1 bXB0aW9ucywgYnV0IHRoZSBtb3JlIG9mdGVuIHdlIGNhbiBnaXZlIHRoZSB1c2VycyBhIGNvbXBs ZXRlIGxpc3Qgb2Ygc2ltaWxhciBsb2NhdGlvbnMsIHRoZSBtb3JlIGVmZmVjdGl2ZSB0aGlzIGV4 dGVuc2lvbiB3aWxsIGJlLiAgU28sIEkgdGhpbmsgYW4gZXhwbGljaXQgaW5kaWNhdGlvbiB3aWxs IGJlIGhlbHBmdWwuICBBdCB0aGUgdmVyeSBsZWFzdCwgaXQgc2hvdWxkIHNhdmUgYSBzdXBwb3J0 IGNhbGwgb3IgdHdvICjigJxJZiB0aGUgTFZGIGtuZXcgdGhhdCB1bml0IDUwMSB3YXMgdmFsaWQs IHRoZW4gd2h5IGRpZCBpdCBvbmx5IHN1Z2dlc3QgMTAxLCAxMDMsIDIwMSwgMjAyLCBhbmQgMjAz P+KAnSkNCg0KRGFuDQoNCkZyb206IFJvc2VuLCBCcmlhbiBbbWFpbHRvOkJyaWFuLlJvc2VuQG5l dXN0YXIuYml6XQ0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDE3LCAyMDE2IDQ6MjQgUE0NClRvOiBE YW4gQmFua3M7IGVjcml0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogZHJhZnQtaWV0Zi1lY3JpdC1z aW1pbGFyLWxvY2F0aW9uLTAzIGZlZWRiYWNrIC0gYWRkaXRpb25hbA0KDQpJIGRvbuKAmXQgcmVh bGx5IGhhdmUgYSBwcm9ibGVtIHdpdGggaGF2aW5nIHRoaXMgb3B0aW9uLCBidXQgb25lIHF1ZXN0 aW9uIEkgaGF2ZSBpcyB3aGF0IHdvdWxkIHRoZSBjbGllbnQgZG8gd2l0aCB0aGF0IGluZm9ybWF0 aW9uPyAgSSBjYW7igJl0IHRoaW5rIG9mIGFueSBiZWhhdmlvciBjaGFuZ2UgdGhhdCByZXR1cm4g b2YgdGhhdCBpbmZvcm1hdGlvbiB3b3VsZCB0cmlnZ2VyLg0KDQpCcmlhbg0KDQpGcm9tOiBEYW4g QmFua3MgPERCYW5rc0BkZHRpLm5ldDxtYWlsdG86REJhbmtzQGRkdGkubmV0Pj4NCkRhdGU6IE1v bmRheSwgT2N0b2JlciAxNywgMjAxNiBhdCA0OjE4IFBNDQpUbzogImVjcml0QGlldGYub3JnPG1h aWx0bzplY3JpdEBpZXRmLm9yZz4iIDxlY3JpdEBpZXRmLm9yZzxtYWlsdG86ZWNyaXRAaWV0Zi5v cmc+Pg0KQ2M6IEJyaWFuIFJvc2VuIDxicmlhbi5yb3NlbkBuZXVzdGFyLmJpejxtYWlsdG86YnJp YW4ucm9zZW5AbmV1c3Rhci5iaXo+Pg0KU3ViamVjdDogZHJhZnQtaWV0Zi1lY3JpdC1zaW1pbGFy LWxvY2F0aW9uLTAzIGZlZWRiYWNrIC0gYWRkaXRpb25hbA0KDQpUaGVyZSBpcyBvbmUgdGhpbmcg SSB3b3VsZCBsaWtlIHRvIGFkZCB0byB0aGUgZmVlZGJhY2sgd2hpY2ggSSBzZW50IHJlY2VudGx5 IG9uIHRoZSBzaW1pbGFyIGxvY2F0aW9uIGRyYWZ0Og0KDQpTZWN0aW9uIDQgZGlzY3Vzc2VzIGJy aWVmbHkgdGhlIHBvc3NpYmlsaXR5IG9mIHRoZSBzZXJ2ZXIgbGltaXRpbmcgdGhlIG51bWJlciBv ZiByZXR1cm5lZCBzaW1pbGFyIGxvY2F0aW9ucy4gIEFsdGhvdWdoIHRoZSBjdXJyZW50IHRleHQg ZXhwcmVzc2VzIHRoZSBnZW5lcmFsIGlkZWEgdGhhdCB0aGVyZSBtYXkgYmUgYSBmZXcgdGhhdCBh cmUgdGhlIOKAnG1vc3QgbGlrZWx54oCdIHRvIGJlIHRoZSBjb3JyZWN0IGxvY2F0aW9uLCB0aGVy ZSBhcmUgYWxzbyBzY2VuYXJpb3Mgd2hlcmUgbWFueSBzaW1pbGFyIGxvY2F0aW9ucyBjb3VsZCBh bGwgYmUgZXF1YWxseSBsaWtlbHksIGFuZCB0aGUgc2VydmVyIG1pZ2h0IG5lZWQgdG8gc2ltcGx5 IGN1dCBvZmYgdGhlIGxpc3QgYXQgYSByZWFzb25hYmxlIGNvdW50LiAgSW4gdGhvc2Ugc2l0dWF0 aW9ucywgSSBiZWxpZXZlIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgdGhlIHNlcnZlciBpbmRpY2F0 ZWQgd2hlbiBzdWNoICBhIGxpbWl0IGlzIGFjdHVhbGx5IGFwcGxpZWQuDQoNCkkgc3VnZ2VzdCB0 aGF0IGFuIGF0dHJpYnV0ZSBiZSBhZGRlZCB0byB0aGUgbG9jYXRpb25WYWxpZGF0aW9uIGVsZW1l bnQgb2YgdGhlIGZpbmRTZXJ2aWNlIHJlc3BvbnNlLCBwZXJoYXBzIHJsaTpzaW1pbGFyTG9jYXRp b25zTGltaXRlZCwgaGF2aW5nIGEgZGF0YSB0eXBlIG9mIGJvb2xlYW4sIHdpdGggaW5zdHJ1Y3Rp b25zIHRoYXQgYSBzZXJ2ZXIgU0hPVUxEIGluY2x1ZGUgdGhpcyBhdHRyaWJ1dGUgaWYgdGhlIG51 bWJlciBvZiByZXR1cm5lZCBzaW1pbGFyIGxvY2F0aW9ucyBpcyBsaW1pdGVkIGR1ZSB0byBjb25m aWd1cmF0aW9uIG9yIHBvbGljeS4NCg0KRGFuIEJhbmtzDQo= --_000_MWHPR17MB10713730C2A09CD1B0FFC4A9A7D00MWHPR17MB1071namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiM0NDU0NkE7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMw NTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzQ0NTQ2QSI+SeKAmW0gdGhpbmtp bmcgb2YgYW4gZXhhbXBsZSB3aGVyZSB5b3UgbWlnaHQgYSBsYXJnZSBhcGFydG1lbnQgYnVpbGRp bmcsIGFuZCBhIHF1ZXJ5IHRoYXQgZGlkIG5vdCBpbmNsdWRlIHVuaXQgb3IgZmxvb3IuJm5ic3A7 IElmIHRoZSByZXNwb25zZSBvbmx5IGxpc3RzIHRoZSBmaXJzdCA1IHVuaXRzIGFzIHNpbWlsYXIg bG9jYXRpb25zLCBhIHBlcnNvbiBsb29raW5nIGF0IHRoaXMNCiBtaWdodCAoaW5jb3JyZWN0bHkp IGFzc3VtZSB0aGF0IHRoZSBzZXJ2ZXIgZG9lc27igJl0IGhhdmUgZGF0YSBmb3IgdGhlIG90aGVy IDEzIHVuaXRzIGluIHRoYXQgYnVpbGRpbmcuJm5ic3A7IE9mIGNvdXJzZSwgdGhlcmUgaXMgYWxy ZWFkeSBhIGdvb2QgZGlzY2xhaW1lciBpbiB0aGUgZHJhZnQgbm90IHRvIG1ha2Ugc3VjaCBhc3N1 bXB0aW9ucywgYnV0IHRoZSBtb3JlIG9mdGVuIHdlIGNhbiBnaXZlIHRoZSB1c2VycyBhIGNvbXBs ZXRlIGxpc3Qgb2Ygc2ltaWxhcg0KIGxvY2F0aW9ucywgdGhlIG1vcmUgZWZmZWN0aXZlIHRoaXMg ZXh0ZW5zaW9uIHdpbGwgYmUuJm5ic3A7IFNvLCBJIHRoaW5rIGFuIGV4cGxpY2l0IGluZGljYXRp b24gd2lsbCBiZSBoZWxwZnVsLiZuYnNwOyBBdCB0aGUgdmVyeSBsZWFzdCwgaXQgc2hvdWxkIHNh dmUgYSBzdXBwb3J0IGNhbGwgb3IgdHdvICjigJxJZiB0aGUgTFZGIGtuZXcgdGhhdCB1bml0IDUw MSB3YXMgdmFsaWQsIHRoZW4gd2h5IGRpZCBpdCBvbmx5IHN1Z2dlc3QgMTAxLCAxMDMsIDIwMSwg MjAyLA0KIGFuZCAyMDM/4oCdKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojNDQ1NDZBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzQ0NTQ2QSI+ RGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM0NDU0NkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJvc2VuLCBCcmlhbiBbbWFpbHRvOkJy aWFuLlJvc2VuQG5ldXN0YXIuYml6XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgT2N0b2Jl ciAxNywgMjAxNiA0OjI0IFBNPGJyPg0KPGI+VG86PC9iPiBEYW4gQmFua3M7IGVjcml0QGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBkcmFmdC1pZXRmLWVjcml0LXNpbWlsYXItbG9j YXRpb24tMDMgZmVlZGJhY2sgLSBhZGRpdGlvbmFsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2NvbG9yOmJsYWNrIj5JIGRvbuKAmXQgcmVhbGx5IGhhdmUgYSBwcm9ibGVtIHdpdGggaGF2aW5n IHRoaXMgb3B0aW9uLCBidXQgb25lIHF1ZXN0aW9uIEkgaGF2ZSBpcyB3aGF0IHdvdWxkIHRoZSBj bGllbnQgZG8gd2l0aCB0aGF0IGluZm9ybWF0aW9uPyAmbmJzcDtJIGNhbuKAmXQgdGhpbmsgb2Yg YW55IGJlaGF2aW9yIGNoYW5nZSB0aGF0IHJldHVybiBvZiB0aGF0IGluZm9ybWF0aW9uDQogd291 bGQgdHJpZ2dlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkJyaWFu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RGFuIEJhbmtzICZsdDs8YSBocmVmPSJt YWlsdG86REJhbmtzQGRkdGkubmV0Ij5EQmFua3NAZGR0aS5uZXQ8L2E+Jmd0Ozxicj4NCjxiPkRh dGU6IDwvYj5Nb25kYXksIE9jdG9iZXIgMTcsIDIwMTYgYXQgNDoxOCBQTTxicj4NCjxiPlRvOiA8 L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmVjcml0QGlldGYub3JnIj5lY3JpdEBpZXRmLm9yZzwv YT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzplY3JpdEBpZXRmLm9yZyI+ZWNyaXRAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+QnJpYW4gUm9zZW4gJmx0OzxhIGhyZWY9Im1haWx0 bzpicmlhbi5yb3NlbkBuZXVzdGFyLmJpeiI+YnJpYW4ucm9zZW5AbmV1c3Rhci5iaXo8L2E+Jmd0 Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5kcmFmdC1pZXRmLWVjcml0LXNpbWlsYXItbG9jYXRpb24t MDMgZmVlZGJhY2sgLSBhZGRpdGlvbmFsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRo ZXJlIGlzIG9uZSB0aGluZyBJIHdvdWxkIGxpa2UgdG8gYWRkIHRvIHRoZSBmZWVkYmFjayB3aGlj aCBJIHNlbnQgcmVjZW50bHkgb24gdGhlIHNpbWlsYXIgbG9jYXRpb24gZHJhZnQ6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNlY3Rpb24gNCBkaXNjdXNzZXMgYnJpZWZseSB0aGUg cG9zc2liaWxpdHkgb2YgdGhlIHNlcnZlciBsaW1pdGluZyB0aGUgbnVtYmVyIG9mIHJldHVybmVk IHNpbWlsYXIgbG9jYXRpb25zLiZuYnNwOyBBbHRob3VnaCB0aGUgY3VycmVudCB0ZXh0IGV4cHJl c3NlcyB0aGUgZ2VuZXJhbCBpZGVhIHRoYXQgdGhlcmUgbWF5IGJlIGEgZmV3IHRoYXQgYXJlIHRo ZSDigJxtb3N0IGxpa2VseeKAnQ0KIHRvIGJlIHRoZSBjb3JyZWN0IGxvY2F0aW9uLCB0aGVyZSBh cmUgYWxzbyBzY2VuYXJpb3Mgd2hlcmUgbWFueSBzaW1pbGFyIGxvY2F0aW9ucyBjb3VsZCBhbGwg YmUgZXF1YWxseSBsaWtlbHksIGFuZCB0aGUgc2VydmVyIG1pZ2h0IG5lZWQgdG8gc2ltcGx5IGN1 dCBvZmYgdGhlIGxpc3QgYXQgYSByZWFzb25hYmxlIGNvdW50LiZuYnNwOyBJbiB0aG9zZSBzaXR1 YXRpb25zLCBJIGJlbGlldmUgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB0aGUgc2VydmVyIGluZGlj YXRlZA0KIHdoZW4gc3VjaCAmbmJzcDthIGxpbWl0IGlzIGFjdHVhbGx5IGFwcGxpZWQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkkgc3VnZ2VzdCB0aGF0IGFuIGF0dHJpYnV0ZSBi ZSBhZGRlZCB0byB0aGUgbG9jYXRpb25WYWxpZGF0aW9uIGVsZW1lbnQgb2YgdGhlIGZpbmRTZXJ2 aWNlIHJlc3BvbnNlLCBwZXJoYXBzIHJsaTpzaW1pbGFyTG9jYXRpb25zTGltaXRlZCwgaGF2aW5n IGEgZGF0YSB0eXBlIG9mIGJvb2xlYW4sIHdpdGggaW5zdHJ1Y3Rpb25zIHRoYXQgYSBzZXJ2ZXIg U0hPVUxEIGluY2x1ZGUNCiB0aGlzIGF0dHJpYnV0ZSBpZiB0aGUgbnVtYmVyIG9mIHJldHVybmVk IHNpbWlsYXIgbG9jYXRpb25zIGlzIGxpbWl0ZWQgZHVlIHRvIGNvbmZpZ3VyYXRpb24gb3IgcG9s aWN5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5EYW4gQmFua3M8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_MWHPR17MB10713730C2A09CD1B0FFC4A9A7D00MWHPR17MB1071namp_-- From nobody Mon Oct 17 16:37:20 2016 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 8C0BB129512 for ; Mon, 17 Oct 2016 16:37:18 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 rIdREfuUaLBC for ; Mon, 17 Oct 2016 16:37:17 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D040A1294EB for ; Mon, 17 Oct 2016 16:37:16 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 17 Oct 2016 16:37:16 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Mon, 17 Oct 2016 16:37:14 -0700 To: Ivo Sedlacek , "ecrit@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 23:37:18 -0000 Hi Ivo, At 12:48 AM +0000 10/17/16, Ivo Sedlacek wrote: > I identified a few issues: > > ISSUE 1: > > section 3 - given that the section 3 contains a lot of information > on legacy eCall in 3GPP, on ETSI requirements on NG-eCall, and CEN > documents, I wonder why the section 3 does not refer to 3GPP TS > 24.229 (particularly subclause 4.7.6) which gives details of > requirements on PSAP for usage of eCall in mobile environment. Reference to TS24.229 added in section 4. Section 3 has higher-level information and background, with references to SDOs rather than documents. Section 4 has references to documents, which is where the reference to TS24.229 was added. > > ISSUE 2: > > section 3 - level of technical detail of the last paragraph of > section 3 does not fit with level of technical detail of the > remaining text of section 3. Intermediate paragraphs were added in version 17. > > ISSUE 3: > > section 4 - add a reference to stage-3 requirements on eCall in > 3GPP TS 24.229. Reference added. > > ISSUE 4: > > section 4, " This document registers the 'application/ > emergencyCallData.eCall.MSD+per' MIME Content-Type to enable the MSD > to be carried in SIP." > > There is no MIME Content-Type registry. "MIME Content-Type" -> "MIME type" > > Same in other places of the document. Corrected "content type" to "media type". > ISSUE 6: > > section 6 - "An MSD or a metadata/control block is always enclosed > in a multipart > body part (even if it would otherwise be the only body part in the > SIP message)." - which multipart MIME type is meant? > multipart/mixed or multipart/alternative or .... We do not need to specify that in this text. > > ISSUE 7 > > section 6 - "The IVS then attaches an updated MSD to a SIP > INFO request and sends it within the dialog." - what is meant by > "attaching MSD to SIP INFO request"? I think that's made abundantly clear in the multiple earlier instances in the same section that say "as a MIME body part". > > ISSUE 8 > > section 9 - " If the IVS receives a SIP response without the > metadata/control > block, it indicates that the SIP dialog is not an NG-eCall (e.g., > some part of the call is being handled as a legacy call)." - > needs to talk about final responses only, as earlier text states "A > metadata/control object is not attached to provisional (e.g., 180) > responses." Agreed, fixed. > > ISSUE 9 > > section 9 - what is "SIP status message"? I do not see "SIP status message" anywhere in the document. > > ISSUE 10 > > " > For > example, if a PSAP is unable to accept an eCall (e.g., due to > overload or too many calls from the same location), it can reject the > INVITE. Since a metadata/control object is also included in the SIP > response that rejects the call, the IVS knows if the PSAP received > the MSD, and can inform the vehicle occupants that the PSAP > successfully received the vehicle location and information but can't > talk to the occupants at that time." - this prevents persons in > the car from getting emergency service of the PSAP using other > means (e.g. using circuit switched network). Possibility for DOS > attack. If the PSAP is overloaded (e.g., there is a very large multi-vehicle incident, or another large-scale emergency incident), then there are likely to be multiple simultaneous eCall attempts. The document does not in any way dictate or mandate PSAP response. PSAPs are free to respond as they choose. E.g., a PSAP can accept eCalls and add them to a queue, a PSAP can reject an eCall and include an ack with "received=false", a PSAP can reject an eCall and include an ack with "received=true". Doing the latter indicates that the PSAP has received the MSD and hence is aware of the incident. > > ISSUE 11 > > "The body for an emergencyCallData.eCall.MSD info package is a > multipart body." - which multipart MIME type is meant? > multipart/mixed or multipart/alternative or .... We do not need to get into that level of detail in this text. > > ISSUE 12 > > "Zero or one application/ > emergencyCallData.eCall.MSD+per part (containing an MSD) and zero or > more application/emergencyCallData.control+xml (containing a > metadata/control object) parts are permitted." - this allows > INFO with no body part at all. If this is intentional, describe > when it is supposed to be used. If this is not intentional, state > that at least one of both is present. I clarified this, thanks for catching it. > > ISSUE 13 > > "Intermediate multipart > body parts MAY appear." - what does it mean? Where is > "Intermediate multipart body part" defined? The text was deleted in version -16. > > ISSUE 14 > > "while others can be > expected to carry an occasional request" - meaning of > "occasional" can be whatever, it depends on perspective of the user > - once per milisecond, once per second, once per minute, once per > hour or once per day? Other text makes it clear that a request for an updated MSD is generally sent upon manual request of a PSAP call taker who suspects vehicle state may have changed. > > ISSUE 15 > > Figure 8 expects location body by inclusion of Geolocation: > but does not show it. Fixed, thanks for catching this. > > ISSUE 16 > >>From and To in Figure 9 do not fit From and To in Figure 8. Fixed, thanks for catching this. > > ISSUE 17 > >>From in Figure 10 does not contain tag. Fixed, thanks for catching this. > > ISSUE 18 > > Accept in Figure 10 is not correct - INFO response is not expected > to contain body. Fixed, thanks for catching this. > > ISSUE 19 > > To in Figure 11 does not contain tag. Fixed, thanks for catching this. > > ISSUE 20 > > examples contain a value of schemaLocation parameter which is not > aligned with https://www.w3.org/TR/xmlschema-0/#schemaLocation > stating "The schemaLocation attribute value consists of one or more > pairs of URI references, separated by white space. " > > xsi:schemaLocation= > "urn:ietf:params:xml:ns:EmergencyCallData:control" Fixed. > > Kind regards > > Ivo Sedlacek > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Children are natural mimics who act like their parents despite every effort to teach them good manners. From nobody Mon Oct 17 16:42:47 2016 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 354C21299AA; Mon, 17 Oct 2016 16:42:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147674776219.11710.13395425188761702918.idtracker@ietfa.amsl.com> Date: Mon, 17 Oct 2016 16:42:42 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-18.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 23:42:42 -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 of the IETF. Title : Next-Generation Pan-European eCall Authors : Randall Gellens Hannes Tschofenig Filename : draft-ietf-ecrit-ecall-18.txt Pages : 45 Date : 2016-10-17 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of the pan European in- vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles, providing real-time communications and an integrated set of related data. This document also registers MIME media types and an Emergency Call Additional Data Block for the eCall vehicle data and metadata/control data, and an INFO package to enable carrying this data in INFO requests. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-ecall-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-18 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 Mon Oct 17 16:43:03 2016 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 AE32B1299AA; Mon, 17 Oct 2016 16:42:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147674777570.11686.12268367786138734101.idtracker@ietfa.amsl.com> Date: Mon, 17 Oct 2016 16:42:55 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-17.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 23:42:56 -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 of the IETF. Title : Next-Generation Vehicle-Initiated Emergency Calls Authors : Randall Gellens Brian Rosen Hannes Tschofenig Filename : draft-ietf-ecrit-car-crash-17.txt Pages : 43 Date : 2016-10-17 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data. This document also registers a MIME media type and Emergency Call Additional Data Block for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash) and an INFO package to enable carrying this and related data in INFO requests. An external specification for the data format, contents, and structure are referenced in this document. This document reuses the technical aspects of next-generation pan- European eCall (a mandated and standardized system for emergency calls by in-vehicle systems within Europe and other regions). However, this document specifies a different set of vehicle (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This document is an extension of the eCall document, with the primary differences being that this document makes the MSD data set optional and VEDS mandatory, and adds attribute values to the metadata/control object to permit greater functionality. This document registers a new INFO package (identical to that registered for eCall but with the addition of the VEDS MIME type). This document also describes legacy (circuit-switched) ACN systems and their migration to next-generation emergency calling, to provide background information and context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-17 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 Mon Oct 17 16:51:12 2016 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 5EBFC129473 for ; Mon, 17 Oct 2016 16:51:10 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 yy7BGpr9mEeZ for ; Mon, 17 Oct 2016 16:51:09 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3E16B129401 for ; Mon, 17 Oct 2016 16:51:09 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 17 Oct 2016 16:51:06 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <147646451751.18604.4638966497289572815.idtracker@ietfa.amsl.com> <147646453871.18548.7812739569679702499.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Mon, 17 Oct 2016 16:51:04 -0700 To: Az Mankin , Christer Holmberg , Ivo Sedlacek From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] draft-ietf-ecrit-ecall-18.txt and draft-ietf-ecrit-car-crash-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 23:51:11 -0000 ecall-18 and car-crash-17 (just uploaded now) address all comments, including Ivo's. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- We must respect the other fellow's religion, but only in the sense and to the extent that we respect his theory that his wife is beautiful and his children are smart. --H.L. Mencken From nobody Tue Oct 18 02:39:01 2016 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 7DD8A129565 for ; Tue, 18 Oct 2016 02:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 90JpNNnmv-vL for ; Tue, 18 Oct 2016 02:38:58 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 3D31612954F for ; Tue, 18 Oct 2016 02:38:58 -0700 (PDT) X-AuditID: c1b4fb3a-e95069800000099a-45-5805edb0c2e3 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id C8.E6.02458.0BDE5085; Tue, 18 Oct 2016 11:38:56 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.90]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0319.002; Tue, 18 Oct 2016 11:38:51 +0200 From: Christer Holmberg To: Randall Gellens , Az Mankin , Ivo Sedlacek Thread-Topic: draft-ietf-ecrit-ecall-18.txt and draft-ietf-ecrit-car-crash-16.txt Thread-Index: AQHSKNFWuzaq+vwJzUCnNduvzpUM0aCuB+qA Date: Tue, 18 Oct 2016 09:38:51 +0000 Message-ID: References: <147646451751.18604.4638966497289572815.idtracker@ietfa.amsl.com> <147646453871.18548.7812739569679702499.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <9C954144B056804FA09B27399F2EA2FE@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2K7ou6Gt6wRBmvOaVksnbqTyaJx0VNW i+/PuxgdmD12zrrL7rFkyU8mj613HrMEMEdx2aSk5mSWpRbp2yVwZVz5NY254AdrxaJHn1ka GI+wdDFyckgImEjsPnaHuYuRi0NIYD2jxNGlj5kgnMWMEktPvwNyODjYBCwkuv9pgzSICFRL 7Nk2gxXEZhZQlTjX+BhskLBAsMSJ7mnsEDUhEtOur2CFsI0kln75ywZiswDVX7gzC6yeV8Ba Ys/tN4wQu64wSVyf+hJsFyfQReenuIHUMAqISXw/tYYJYpe4xK0n85kgjhaQWLLnPDOELSrx 8vE/VpBWUQE9iTX3wyDCihIfX+1jhGjVkViw+xMbhG0tsWPxXqi4tsSyha+ZIc4RlDg58wnL BEbxWUi2zULSPgtJ+ywk7bOQtC9gZF3FKFqcWlycm25kpJdalJlcXJyfp5eXWrKJERiBB7f8 ttrBePC54yFGAQ5GJR7ehJssEUKsiWXFlbmHGCU4mJVEeO3fsEYI8aYkVlalFuXHF5XmpBYf YpTmYFES5zVbeT9cSCA9sSQ1OzW1ILUIJsvEwSnVwGhU9O/AcrP+Wb2X4ywaEh/Fyfd3XTPb vH6qj39T9Ve2W+Yz1r5sfszfY6lqZJv2fwfjFx/9Bgmukp/qJ9a0aqi/m9h/m79UY4nxp+M6 cTmf61e1LPb9Y/nmf11RxHpRo/9CfvNXrRCz6/8cpfhIwJV5caeQhhDXbfUFN/aLFgffXq56 1lzzthJLcUaioRZzUXEiANRLIY+8AgAA Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-18.txt and draft-ietf-ecrit-car-crash-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 09:38:59 -0000 Hi, Once all comments have been addressed, I think the community should be given a few days to check the latest version of the draft, before the publication request is done. Regards, Christer On 18/10/16 02:51, "Randall Gellens" wrote: >ecall-18 and car-crash-17 (just uploaded now) address all comments, >including Ivo's. > >--=20 >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly selected tag: --------------- >We must respect the other fellow's religion, but only in the sense and to >the extent that we respect his theory that his wife is beautiful and his >children are smart. --H.L. Mencken From nobody Tue Oct 18 05:03:39 2016 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 79723129618 for ; Tue, 18 Oct 2016 05:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 KHJPqR4GnIq1 for ; Tue, 18 Oct 2016 05:03:35 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 8F9F512953E for ; Tue, 18 Oct 2016 05:03:34 -0700 (PDT) X-AuditID: c1b4fb3a-e95069800000099a-4f-58060f948a5f Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 07.FD.02458.49F06085; Tue, 18 Oct 2016 14:03:32 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.66) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 18 Oct 2016 14:02:48 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VUeBU7e4/nOXAuYSbGfH5yQz5FGQ7pxeHYmEpBwNSDM=; b=bElOaQrii9XAlnMVkda2VBkTpOgpgPWru6bKUMB7fv/EWqGkcBxFsBZNKBmLYw4IHfjI1IUE0VfumePdLvDaxfQ/LWA4djfu2fVxvHgAlvVf+qVzwpzr5LpccuKTPNU4UhAqfTNQqfxPrg9IpO4Jyqh5CNiKRR6Xz0vXO9qmr9I= Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) by AM5PR0701MB2465.eurprd07.prod.outlook.com (10.169.153.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Tue, 18 Oct 2016 12:02:48 +0000 Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com ([10.169.153.136]) by AM5PR0701MB2468.eurprd07.prod.outlook.com ([10.169.153.136]) with mapi id 15.01.0679.006; Tue, 18 Oct 2016 12:02:48 +0000 From: Ivo Sedlacek To: Randall Gellens , "ecrit@ietf.org" Thread-Topic: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 Thread-Index: AQHSKM9jDqYN1mg4ykGyzqHQEQ3RAqCuFJfw Date: Tue, 18 Oct 2016 12:02:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ivo.sedlacek@ericsson.com; x-originating-ip: [116.8.4.20] x-ms-office365-filtering-correlation-id: 5721332c-f46a-4127-0859-08d3f74eada8 x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2465; 6:LjoWgxWiRckbk050DWiafXaJXQqZD5nDI4tiUdXHxrmX5pjzFRqmHAqYz7n9lNemZtJEIyIou00p7n1HhDttGsW20eIJZpsUbOUhbRx8sXjcqXNAatmoxZ5Jh3ZVOCCPFEhyhnnLcJd2h6wma4/YHKYfzXcLCDVQsmh/sOpILgs61DK8TWxxlXYmTYWW3ah2TK02x06xCqxkkgV4L+xXNM4msAmIchXU0iO48WqomnyCDL5wbm5JO4Mmdk0zcrbFXkmQWEBTzt6IQ4hlErS7PQXOb/xIUkn/mdtjIs88ItxUpkZLMNasMZ4EDrrjk3Dz; 5:u1nBhqyWmEEHP007tTSBIkOXBqvYIV9n+GOfAxMv1GzTDwtwlrkW+MppD1u7vKA4QkmGTHnasp0z/xR7x9ioFPHAY7rltK0of1oJY3YTCnKdhU949K/jEo6g28+DXocC2oPRIw03wGm78ec6MkzIBQ==; 24:t5SJXvXWOgQ9N6OdsWLChZZ0nXf8d2MJ1ZucB/DAcF6tWgOSRbnFHm5LpUhlQulkh8Jty96AhZS6VJ7T3UMh1cJkHA5EZaYE/em/6H7kEt8=; 7:Vy1kTlNk+gdEh5w0zm+ZUcHPUplfl5Ko8NbUhWenNbt/bPDTQEc8bESQMj1QNHoLYQw5Redyj7E9cfaBz/eqgzocQrS8w0FmXL/CSyA2mkUaCvmj2YXHLmMni+1tRdF0GP3vlT8eS5ssQiXeA4qEZGgrXQWQ8JMJFg4yv3pO4YCab32qeyiF6TfYxAx2LbS3VvhnEBymsbKPFqtlNrdkmw6wN3z+qeBQptUhL5SOzVAOC9FEtZqBbZEHy+2jj6RPUFIiJMqiSXGj0IPAsMAEFhAXfHC0MRm+gTPsi4023Ee9T+dixA5FsFr0hyVY6auNwFPSESjOwSrLB2wswIcHZl+7KOXMbNXBuV8yc5Pdi/o= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0701MB2465; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AM5PR0701MB2465; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2465; x-forefront-prvs: 00997889E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(51444003)(189002)(199003)(3660700001)(86362001)(92566002)(77096005)(66066001)(15975445007)(2501003)(5890100001)(5660300001)(3280700002)(50986999)(230783001)(2906002)(7696004)(76176999)(54356999)(122556002)(93886004)(87936001)(2950100002)(2900100001)(11100500001)(5002640100001)(106116001)(101416001)(106356001)(586003)(3846002)(6116002)(33656002)(102836003)(10400500002)(9686002)(105586002)(8936002)(305945005)(8676002)(7736002)(81166006)(81156014)(76576001)(19580395003)(68736007)(7846002)(189998001)(97736004)(74316002)(5001770100001)(107886002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2465; H:AM5PR0701MB2468.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2016 12:02:48.1031 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2465 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42KZGbHdSXcKP1uEwa/ZyhaNi56yWnx/3sXo wOSxZMlPJo+tdx6zBDBFcdmkpOZklqUW6dslcGW0vt3AVHDarqJn9wW2BsYmgy5GTg4JAROJ 42c2sXQxcnEICaxnlHjScYcVwjnBKPFvyU9GEIdFoJdZ4ujpPYwQmVlMErOnvWAG6RcSOMMo cbPPDMRmE9CTmLjlCFA7B4eIQIhEy3sukLCwgL3E/E2vWEBsEQEHiaddR9ghbCOJ9gubweIs AqoSXS9mgo3kFUiQuLv3NdSu/UC7Nm9mBUlwAt269ddbsGZGATGJ76fWMIHYzALiEreezGeC +EdAYsme88wQtqjEy8f/WCHqYyT+d39mhYjLSXz5vhmq3lfiwJZzbCDLJAQ+sUtMW36CHSLh ITF56U0oO19i/9R+NgjbWuLlud2sEA17GCW+7JoCNUlGYvmXfhaIxBdWiYW9s1khQZQqsXxt KyMkLKQk7l7phLJlJF7c2cs6gVFzFpIvIGwdiQW7P7FB2NoSyxa+Zp4FDhpBiZMzn7AsYGRZ xShanFpcnJtuZKSXWpSZXFycn6eXl1qyiRGYOg5u+W21g/Hgc8dDjAIcjEo8vAk3WSKEWBPL iitzDzFKcDArifAG87JFCPGmJFZWpRblxxeV5qQWH2KU5mBREuc1W3k/XEggPbEkNTs1tSC1 CCbLxMEp1cBoqsuVzL/rRsrZ/cHL3Za3nTrwe/nD128eJFWeuxRZu0Oua97T97t52qcyn/Ht dGxannj2lgb3HI4jT2NvH3vw/uBUq22TcnwfSe8xVS+V4rBa9EShOeDni4lKF2KWn1Zqu6kx wawyPb9TIlLePe+i/pnvNp/OF9ZxvQ7/2dHl9zq9QORW4xl9JZbijERDLeai4kQAcc5aFRkD AAA= Archived-At: Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 12:03:37 -0000 Hello, first of all, I am participating in 3GPP CT1 meeting this week and I have n= ot have time to review changes between -015 and -018 properly. Can we shift= the deadline to next week? I am OK with resolution of ISSUE 1, ISSUE 3, ISSUE 8, ISSUE 13, ISSUE 15, I= SSUE 16, ISSUE 17, ISSUE 19. On the remaining issues: > > ISSUE 2: > > > > section 3 - level of technical detail of the last paragraph of=20 > > section 3 does not fit with level of technical detail of the remaining= =20 > > text of section 3. >=20 > Intermediate paragraphs were added in version 17. I still believe that section 3 contains different types of information: Type1: generic overview of the eCall requirements, existing solutions, ... Type2: information about the draft It would be better to split those to separate sections. > > ISSUE 4: > > > > section 4, " This document registers the 'application/ > > emergencyCallData.eCall.MSD+per' MIME Content-Type to enable the MS= D > > to be carried in SIP." > > > > There is no MIME Content-Type registry. "MIME Content-Type" -> "MIME t= ype" > > > > Same in other places of the document. >=20 > Corrected "content type" to "media type". I can still see a few occurences of "content type" in -018 - e.g. --------- Security considerations: This ****content type**** is designed to car= ry vehicle and incident-related data during an emergency call. This data contains personal information including vehicle VIN, location, direction, etc. Appropriate precautions need to be taken to limit unauthorized access, inappropriate disclosure to third parties, and eavesdropping of this information. In general, it is acceptable for the data to be unprotected while briefly in transit within the Mobile Network Operator (MNO); the MNO is trusted to not permit the data to be accessed by third parties. Sections 7 and Section 8 of [RFC7852] contain more discussion. --------- and --------- The metadata/control block is designed for use with pan-European eCall and also eCall-like systems (i.e., in other regions), and has extension points. Note that eCall-like systems might define their own vehicle data blocks, and so might need to register a new INFO package to accomodate the new data ****content type**** and the metadata= / control object. --------- and -------- This ****content type**** carries metadata and control information= and requests, such as from a Public Safety Answering Point (PSAP) to an In-Vehicle System (IVS) during an emergency call. -------- > > ISSUE 6: > > > > section 6 - "An MSD or a metadata/control block is always enclosed in= =20 > > a multipart > > body part (even if it would otherwise be the only body part in the > > SIP message)." - which multipart MIME type is meant?=20 > > multipart/mixed or multipart/alternative or .... >=20 > We do not need to specify that in this text. IMO, we need to. Else, the UA can provide multipart/mixed while PSAP expect= s multipart/alternative. > > ISSUE 7 > > > > section 6 - "The IVS then attaches an updated MSD to a SIP > > INFO request and sends it within the dialog." - what is meant by=20 > > "attaching MSD to SIP INFO request"? >=20 > I think that's made abundantly clear in the multiple earlier instances in= the=20 > same section that say "as a MIME body part". I do not really know what "attach body to SIP request" means. Likely, othe= r readers will not know it either. A reference to a section defining how to "attach body to SIP request" would= help. > > ISSUE 9 > > > > section 9 - what is "SIP status message"? >=20 > I do not see "SIP status message" anywhere in the document. It was in -015 section 9 but it looks like it was already resolved in -18. > > ISSUE 10 > > > > " > > For > > example, if a PSAP is unable to accept an eCall (e.g., due to > > overload or too many calls from the same location), it can reject t= he > > INVITE. Since a metadata/control object is also included in the SI= P > > response that rejects the call, the IVS knows if the PSAP received > > the MSD, and can inform the vehicle occupants that the PSAP > > successfully received the vehicle location and information but can'= t > > talk to the occupants at that time." - this prevents persons in=20 > > the car from getting emergency service of the PSAP using other means=20 > > (e.g. using circuit switched network). Possibility for DOS attack. >=20 > If the PSAP is overloaded (e.g., there is a very large multi-vehicle=20 > incident, or another large-scale emergency incident), then there are like= ly=20 > to be multiple simultaneous eCall attempts. The document does not in any= way=20 > dictate or mandate PSAP response. PSAPs are free to respond as they choo= se. =20 > E.g., a PSAP can accept eCalls and add them to a queue, a PSAP can reject= an=20 > eCall and include an ack with "received=3Dfalse", a PSAP can reject an eC= all=20 > and include an ack with "received=3Dtrue". Doing the latter indicates th= at the=20 > PSAP has received the MSD and hence is aware of the incident. How can the UA be sure that such response was sent by PSAP and not by an at= tacker, located somewhere between UA and PSAP?=20 Any SIP entity which happens to be in the path of the emergency call INVITE= request can generate a 600 (Busy Everywhere), 486 (Busy Here), and 603 (D= ecline) response and populate it with a particular body. It is at least a security risk and it needs to be documented. > > ISSUE 11 > > > > "The body for an emergencyCallData.eCall.MSD info package is a=20 > > multipart body." - which multipart MIME type is meant? > > multipart/mixed or multipart/alternative or .... >=20 > We do not need to get into that level of detail in this text. IMO, we need to. Else, the UA can provide multipart/mixed while PSAP expect= s multipart/alternative. > > ISSUE 14 > > > > "while others can be > > expected to carry an occasional request" - meaning of "occasional"= =20 > > can be whatever, it depends on perspective of the user > > - once per milisecond, once per second, once per minute, once per hour= =20 > > or once per day? >=20 > Other text makes it clear that a request for an updated MSD is generally = sent=20 > upon manual request of a PSAP call taker who suspects vehicle state may h= ave changed. A statement that the request is expected to be triggered by manual action o= f the PSAP call taker is good, so I suggest to add it to this section too a= s expert reviewer will read it. > > > > ISSUE 18 > > > > Accept in Figure 10 is not correct - INFO response is not expected=20 > > to contain body. >=20 > Fixed, thanks for catching this. in -18, I can still see Accept with multipart/mixed in the INFO request in = Figure 10. IMO, this is wrong as we do NOT expect a body in INFO response. Yes, there = will be a body in subsequent INFO request sent in opposite direction, but t= hat's not impacted by Accept in first INFO request. > > > > ISSUE 20 > > > > examples contain a value of schemaLocation parameter which is not=20 > > aligned with https://www.w3.org/TR/xmlschema-0/#schemaLocation=20 > > stating "The schemaLocation attribute value consists of one or more=20 > > pairs of URI references, separated by white space. " > > > > xsi:schemaLocation=3D > > "urn:ietf:params:xml:ns:EmergencyCallData:control" >=20 > Fixed. I can see in -18, that you chose to remove the information about schema loc= ation from the XML examples. That's OK with me. However, then you can also remove the following as it is not needed any mor= e xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" Kind regards Ivo Sedlacek From nobody Tue Oct 18 06:38:46 2016 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 3C0F8129A5D for ; Tue, 18 Oct 2016 06:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 Qdg87FM_8-dS for ; Tue, 18 Oct 2016 06:38:44 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 DFFC41294C6 for ; Tue, 18 Oct 2016 06:38:43 -0700 (PDT) X-AuditID: c1b4fb2d-5b107980000009f7-a9-580625e1e05f Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 0F.A7.02551.1E526085; Tue, 18 Oct 2016 15:38:41 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.90]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0319.002; Tue, 18 Oct 2016 15:38:40 +0200 From: Christer Holmberg To: Ivo Sedlacek , Randall Gellens , "ecrit@ietf.org" Thread-Topic: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 Thread-Index: AQHSKM9pnC2aMUPzqUuYRM5JMx1G9qCt+/AAgABO/YA= Date: Tue, 18 Oct 2016 13:38:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1F93B6054FB18545BD82875BE36455E5@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2J7iO5DVbYIg1XPrSwaFz1ltfj+vIvR gcljyZKfTB5b7zxmCWCK4rJJSc3JLEst0rdL4MqYe/AZW8FEl4p1934wNzD2m3YxcnJICJhI /P/0ir2LkYtDSGA9o8Ty5ocsEM5iRomDO9YDZTg42AQsJLr/aYM0iAjUSezYtYcVxBYWsJOY 9XMyC0TcXuLr95fMELaVRF/rJrA4i4CqRMfqT8wgY3gFrCXO90ZBjO8CGv+7nw2khlMgUWJR x0ewmYwCYhLfT61hArGZBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/+xgswUFdCTWHM/DCKsKPHx 1T5GiFY9iRtTp7BB2NYSJ04+YYawtSWWLXwNZvMKCEqcnPmEZQKj2Cwk22YhaZ+FpH0WkvZZ SNoXMLKuYhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3ZxAiMqoNbfuvuYFz92vEQowAHoxIPb8JN lggh1sSy4srcQ4wSHMxKIrxXVdgihHhTEiurUovy44tKc1KLDzFKc7AoifOarbwfLiSQnliS mp2aWpBaBJNl4uCUamDU0FZbsOcaV7nnx59Lz08PU/393k7R9dBME87inmopreydjMu1Lvt7 xUryr0ib7276J4fn6hk5nn3xS3s5W5fOill74Wh664YD6WpRUpUr/Sfw5SzJcHLL7GNjv9IZ 9Pxm+Xm+t3wLDqaL3r4e8kGi79eN/G8tLE6XeUp6blbPXfNvpcjklXxKLMUZiYZazEXFiQAr qQutpgIAAA== Archived-At: Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 13:38:46 -0000 Hi, Regarding indicating the type of multipart (mixed, alternative etc), I agree with Ivo.=20 Unfortunately RFC 6086 doesn=B9t normatively define the type either (in the examples multipart/mixed is used, though), why I think it=B9s even more important to do it in draft-ecall. Regards, Christer On 18/10/16 15:02, "Ecrit on behalf of Ivo Sedlacek" wrote: >Hello, > >first of all, I am participating in 3GPP CT1 meeting this week and I have >not have time to review changes between -015 and -018 properly. Can we >shift the deadline to next week? > >I am OK with resolution of ISSUE 1, ISSUE 3, ISSUE 8, ISSUE 13, ISSUE 15, >ISSUE 16, ISSUE 17, ISSUE 19. > >On the remaining issues: > >> > ISSUE 2: >> > >> > section 3 - level of technical detail of the last paragraph of >> > section 3 does not fit with level of technical detail of the >>remaining=20 >> > text of section 3. >>=20 >> Intermediate paragraphs were added in version 17. > >I still believe that section 3 contains different types of information: >Type1: generic overview of the eCall requirements, existing solutions, ... >Type2: information about the draft > >It would be better to split those to separate sections. > >> > ISSUE 4: >> > >> > section 4, " This document registers the 'application/ >> > emergencyCallData.eCall.MSD+per' MIME Content-Type to enable the >>MSD >> > to be carried in SIP." >> > >> > There is no MIME Content-Type registry. "MIME Content-Type" -> "MIME >>type" >> > >> > Same in other places of the document. >>=20 >> Corrected "content type" to "media type". > >I can still see a few occurences of "content type" in -018 - e.g. > >--------- > Security considerations: This ****content type**** is designed to >carry > vehicle and incident-related data during an emergency call. This > data contains personal information including vehicle VIN, > location, direction, etc. Appropriate precautions need to be > taken to limit unauthorized access, inappropriate disclosure to > third parties, and eavesdropping of this information. In general, > it is acceptable for the data to be unprotected while briefly in > transit within the Mobile Network Operator (MNO); the MNO is > trusted to not permit the data to be accessed by third parties. > Sections 7 and Section 8 of [RFC7852] contain more discussion. >--------- >and >--------- > The metadata/control block is designed for use with pan-European > eCall and also eCall-like systems (i.e., in other regions), and has > extension points. Note that eCall-like systems might define their > own vehicle data blocks, and so might need to register a new INFO > package to accomodate the new data ****content type**** and the >metadata/ > control object. >--------- >and >-------- > This ****content type**** carries metadata and control >information and > requests, such as from a Public Safety Answering Point (PSAP) > to an In-Vehicle System (IVS) during an emergency call. >-------- > >> > ISSUE 6: >> > >> > section 6 - "An MSD or a metadata/control block is always enclosed >>in=20 >> > a multipart >> > body part (even if it would otherwise be the only body part in the >> > SIP message)." - which multipart MIME type is meant? >> > multipart/mixed or multipart/alternative or .... >>=20 >> We do not need to specify that in this text. > >IMO, we need to. Else, the UA can provide multipart/mixed while PSAP >expects multipart/alternative. > >> > ISSUE 7 >> > >> > section 6 - "The IVS then attaches an updated MSD to a SIP >> > INFO request and sends it within the dialog." - what is meant by >> > "attaching MSD to SIP INFO request"? >>=20 >> I think that's made abundantly clear in the multiple earlier instances >>in the=20 >> same section that say "as a MIME body part". > >I do not really know what "attach body to SIP request" means. Likely, >other readers will not know it either. > >A reference to a section defining how to "attach body to SIP request" >would help. > > >> > ISSUE 9 >> > >> > section 9 - what is "SIP status message"? >>=20 >> I do not see "SIP status message" anywhere in the document. > >It was in -015 section 9 but it looks like it was already resolved in -18. > > >> > ISSUE 10 >> > >> > " >> > For >> > example, if a PSAP is unable to accept an eCall (e.g., due to >> > overload or too many calls from the same location), it can reject >>the >> > INVITE. Since a metadata/control object is also included in the >>SIP >> > response that rejects the call, the IVS knows if the PSAP received >> > the MSD, and can inform the vehicle occupants that the PSAP >> > successfully received the vehicle location and information but >>can't >> > talk to the occupants at that time." - this prevents persons in >> > the car from getting emergency service of the PSAP using other means >> > (e.g. using circuit switched network). Possibility for DOS attack. >>=20 >> If the PSAP is overloaded (e.g., there is a very large multi-vehicle >> incident, or another large-scale emergency incident), then there are >>likely=20 >> to be multiple simultaneous eCall attempts. The document does not in >>any way=20 >> dictate or mandate PSAP response. PSAPs are free to respond as they >>choose. =20 >> E.g., a PSAP can accept eCalls and add them to a queue, a PSAP can >>reject an=20 >> eCall and include an ack with "received=3Dfalse", a PSAP can reject an >>eCall=20 >> and include an ack with "received=3Dtrue". Doing the latter indicates >>that the=20 >> PSAP has received the MSD and hence is aware of the incident. > >How can the UA be sure that such response was sent by PSAP and not by an >attacker, located somewhere between UA and PSAP? > >Any SIP entity which happens to be in the path of the emergency call >INVITE request can generate a 600 (Busy Everywhere), 486 (Busy Here), >and 603 (Decline) response and populate it with a particular body. > >It is at least a security risk and it needs to be documented. > >> > ISSUE 11 >> > >> > "The body for an emergencyCallData.eCall.MSD info package is a >> > multipart body." - which multipart MIME type is meant? >> > multipart/mixed or multipart/alternative or .... >>=20 >> We do not need to get into that level of detail in this text. > >IMO, we need to. Else, the UA can provide multipart/mixed while PSAP >expects multipart/alternative. > >> > ISSUE 14 >> > >> > "while others can be >> > expected to carry an occasional request" - meaning of >>"occasional"=20 >> > can be whatever, it depends on perspective of the user >> > - once per milisecond, once per second, once per minute, once per >>hour=20 >> > or once per day? >>=20 >> Other text makes it clear that a request for an updated MSD is >>generally sent=20 >> upon manual request of a PSAP call taker who suspects vehicle state may >>have changed. > >A statement that the request is expected to be triggered by manual action >of the PSAP call taker is good, so I suggest to add it to this section >too as expert reviewer will read it. > >> > >> > ISSUE 18 >> > >> > Accept in Figure 10 is not correct - INFO response is not expected >> > to contain body. >>=20 >> Fixed, thanks for catching this. > >in -18, I can still see Accept with multipart/mixed in the INFO request >in Figure 10. > >IMO, this is wrong as we do NOT expect a body in INFO response. Yes, >there will be a body in subsequent INFO request sent in opposite >direction, but that's not impacted by Accept in first INFO request. > >> > >> > ISSUE 20 >> > >> > examples contain a value of schemaLocation parameter which is not >> > aligned with https://www.w3.org/TR/xmlschema-0/#schemaLocation >> > stating "The schemaLocation attribute value consists of one or more >> > pairs of URI references, separated by white space. " >> > >> > xsi:schemaLocation=3D >> > "urn:ietf:params:xml:ns:EmergencyCallData:control" >>=20 >> Fixed. > >I can see in -18, that you chose to remove the information about schema >location from the XML examples. >That's OK with me. > >However, then you can also remove the following as it is not needed any >more > > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > >Kind regards > >Ivo Sedlacek > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From nobody Tue Oct 18 09:12:10 2016 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 E5EA11296B7 for ; Tue, 18 Oct 2016 09:12:07 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 kAsycgwt-ENp for ; Tue, 18 Oct 2016 09:12:06 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6630512962B for ; Tue, 18 Oct 2016 09:12:06 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 18 Oct 2016 09:12:05 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Tue, 18 Oct 2016 09:12:03 -0700 To: Ivo Sedlacek , Az Mankin , "ecrit@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 16:12:08 -0000 Hi Ivo, I think we can address any remaining comments as part of IETF Last Call. --Randy At 12:02 PM +0000 10/18/16, Ivo Sedlacek wrote: > Hello, > > first of all, I am participating in 3GPP CT1 meeting this week and > I have not have time to review changes between -015 and -018 > properly. Can we shift the deadline to next week? > > I am OK with resolution of ISSUE 1, ISSUE 3, ISSUE 8, ISSUE 13, > ISSUE 15, ISSUE 16, ISSUE 17, ISSUE 19. > > On the remaining issues: > >> > ISSUE 2: >> > >> > section 3 - level of technical detail of the last paragraph of >> > section 3 does not fit with level of technical detail of the remaining >> > text of section 3. >> >> Intermediate paragraphs were added in version 17. > > I still believe that section 3 contains different types of information: > Type1: generic overview of the eCall requirements, existing solutions, ... > Type2: information about the draft > > It would be better to split those to separate sections. Can you elaborate on what the problem is? > >> > ISSUE 4: >> > >> > section 4, " This document registers the 'application/ >> > emergencyCallData.eCall.MSD+per' MIME Content-Type to enable the MSD >> > to be carried in SIP." >> > >> > There is no MIME Content-Type registry. "MIME Content-Type" -> >> "MIME type" >> > >> > Same in other places of the document. >> >> Corrected "content type" to "media type". > > I can still see a few occurences of "content type" in -018 - e.g. Thanks, I'll do a grep. > > --------- > Security considerations: This ****content type**** is designed to carry > vehicle and incident-related data during an emergency call. This > data contains personal information including vehicle VIN, > location, direction, etc. Appropriate precautions need to be > taken to limit unauthorized access, inappropriate disclosure to > third parties, and eavesdropping of this information. In general, > it is acceptable for the data to be unprotected while briefly in > transit within the Mobile Network Operator (MNO); the MNO is > trusted to not permit the data to be accessed by third parties. > Sections 7 and Section 8 of [RFC7852] contain more discussion. > --------- > and > --------- > The metadata/control block is designed for use with pan-European > eCall and also eCall-like systems (i.e., in other regions), and has > extension points. Note that eCall-like systems might define their > own vehicle data blocks, and so might need to register a new INFO > package to accomodate the new data ****content type**** and the metadata/ > control object. > --------- > and > -------- > This ****content type**** carries metadata and control > information and > requests, such as from a Public Safety Answering Point (PSAP) > to an In-Vehicle System (IVS) during an emergency call. > -------- > >> > ISSUE 6: >> > >> > section 6 - "An MSD or a metadata/control block is always enclosed in >> > a multipart >> > body part (even if it would otherwise be the only body part in the >> > SIP message)." - which multipart MIME type is meant? >> > multipart/mixed or multipart/alternative or .... >> >> We do not need to specify that in this text. > > IMO, we need to. Else, the UA can provide multipart/mixed while > PSAP expects multipart/alternative. It would be hard to imagine a use case where a UA generates multipart/alternative. However, I don't mind adding text clarifying that multipart/mixed is expected. > >> > ISSUE 7 >> > >> > section 6 - "The IVS then attaches an updated MSD to a SIP >> > INFO request and sends it within the dialog." - what is meant by >> > "attaching MSD to SIP INFO request"? >> >> I think that's made abundantly clear in the multiple earlier >> instances in the >> same section that say "as a MIME body part". > > I do not really know what "attach body to SIP request" means. > Likely, other readers will not know it either. > > A reference to a section defining how to "attach body to SIP > request" would help. It's the same section, just a little bit before. > > >> > ISSUE 9 >> > >> > section 9 - what is "SIP status message"? >> >> I do not see "SIP status message" anywhere in the document. > > It was in -015 section 9 but it looks like it was already resolved in -18. > > >> > ISSUE 10 >> > >> > " >> > For >> > example, if a PSAP is unable to accept an eCall (e.g., due to >> > overload or too many calls from the same location), it can reject the >> > INVITE. Since a metadata/control object is also included in the SIP >> > response that rejects the call, the IVS knows if the PSAP received >> > the MSD, and can inform the vehicle occupants that the PSAP >> > successfully received the vehicle location and information but can't >> > talk to the occupants at that time." - this prevents persons in >> > the car from getting emergency service of the PSAP using other means >> > (e.g. using circuit switched network). Possibility for DOS attack. >> >> If the PSAP is overloaded (e.g., there is a very large multi-vehicle >> incident, or another large-scale emergency incident), then there are likely >> to be multiple simultaneous eCall attempts. The document does not >> in any way >> dictate or mandate PSAP response. PSAPs are free to respond as >> they choose. >> E.g., a PSAP can accept eCalls and add them to a queue, a PSAP can reject an >> eCall and include an ack with "received=false", a PSAP can reject an eCall >> and include an ack with "received=true". Doing the latter >> indicates that the >> PSAP has received the MSD and hence is aware of the incident. > > How can the UA be sure that such response was sent by PSAP and not > by an attacker, located somewhere between UA and PSAP? > > Any SIP entity which happens to be in the path of the emergency > call INVITE request can generate a 600 (Busy Everywhere), 486 > (Busy Here), and 603 (Decline) response and populate it with a > particular body. > > It is at least a security risk and it needs to be documented. OK, I'll add some text. > >> > ISSUE 11 >> > >> > "The body for an emergencyCallData.eCall.MSD info package is a >> > multipart body." - which multipart MIME type is meant? >> > multipart/mixed or multipart/alternative or .... >> >> We do not need to get into that level of detail in this text. > > IMO, we need to. Else, the UA can provide multipart/mixed while > PSAP expects multipart/alternative. Same answer as above. > >> > ISSUE 14 >> > >> > "while others can be >> > expected to carry an occasional request" - meaning of "occasional" >> > can be whatever, it depends on perspective of the user >> > - once per milisecond, once per second, once per minute, once per hour >> > or once per day? >> >> Other text makes it clear that a request for an updated MSD is >> generally sent >> upon manual request of a PSAP call taker who suspects vehicle >> state may have changed. > > A statement that the request is expected to be triggered by manual > action of the PSAP call taker is good, so I suggest to add it to > this section too as expert reviewer will read it. OK, I'll add text. > >> > >> > ISSUE 18 >> > >> > Accept in Figure 10 is not correct - INFO response is not expected >> > to contain body. >> >> Fixed, thanks for catching this. > > in -18, I can still see Accept with multipart/mixed in the INFO > request in Figure 10. I don't see it. Here is Figure 10: INFO sip:+13145551111@example.com SIP/2.0 To: ;tag=9fxced76sl From: Exemplar PSAP ;tag=8gydfe65t0 Call-ID: 3848276298220188511@atlanta.example.com Call-Info: ; purpose=emergencyCallData.control CSeq: 41862 INFO Info-Package: emergencyCallData.eCall.MSD Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, SUBSCRIBE, NOTIFY, UPDATE Content-Type: multipart/mixed; boundary=boundaryZZZ Content-Dispositio: Info-Package Content-Length: ... --boundaryZZZ Content-Disposition: by-reference Content-Type: application/emergencyCallData.control+xml Content-ID: <3456789012@atlanta.example.com> --boundaryZZZ-- Figure 10: INFO requesting MSD > > IMO, this is wrong as we do NOT expect a body in INFO response. > Yes, there will be a body in subsequent INFO request sent in > opposite direction, but that's not impacted by Accept in first INFO > request. > >> > >> > ISSUE 20 >> > >> > examples contain a value of schemaLocation parameter which is not >> > aligned with https://www.w3.org/TR/xmlschema-0/#schemaLocation >> > stating "The schemaLocation attribute value consists of one or more >> > pairs of URI references, separated by white space. " >> > >> > xsi:schemaLocation= >> > "urn:ietf:params:xml:ns:EmergencyCallData:control" >> >> Fixed. > > I can see in -18, that you chose to remove the information about > schema location from the XML examples. > That's OK with me. > > However, then you can also remove the following as it is not needed any more > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" I've asked Hannes to verify the XML schema and examples as part of IETF Last Call. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Question Authority. They usually know where the bathroom is. --MTV's 'Daria' From nobody Tue Oct 18 09:16:32 2016 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 5DBC71294A4 for ; Tue, 18 Oct 2016 09:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 mVtorP32DWFE for ; Tue, 18 Oct 2016 09:16:28 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 F193E12964E for ; Tue, 18 Oct 2016 09:16:27 -0700 (PDT) X-AuditID: c1b4fb3a-aa3ff7000000099a-84-58064ad85623 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id A8.BC.02458.8DA46085; Tue, 18 Oct 2016 18:16:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.90]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0319.002; Tue, 18 Oct 2016 18:16:23 +0200 From: Christer Holmberg To: Randall Gellens , Ivo Sedlacek , Az Mankin , "ecrit@ietf.org" Thread-Topic: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 Thread-Index: AQHSKM9pnC2aMUPzqUuYRM5JMx1G9qCuYyYPgAAA8iA= Date: Tue, 18 Oct 2016 16:16:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BDB34E1@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7n+4tL7YIgx/nJSyWTt3JZNG46Cmr xffnXYwOzB47Z91l91iy5CeTx9Y7j1kCmKO4bFJSczLLUov07RK4Mma9OMZUsCukYt60M6wN jB/suxg5OSQETCSWTdnM1MXIxSEksJ5R4v2MJkaQhJDAYkaJLYvCuxg5ONgELCS6/2mD1IgI LGCU2PmziQ2kRljATmLClGnMILaIgL3E1+8vmUHqRQSsJO4e5gAJswioSmzfuY8VxOYV8JX4 96mPEWLXQWaJXVsPgCU4gY6Y/H4jE4jNKCAm8f3UGjCbWUBc4taT+UwQhwpILNlznhnCFpV4 +fgfK4StJLHo9meoeh2JBbs/sUHY2hLLFr5mhlgsKHFy5hOWCYwis5CMnYWkZRaSlllIWhYw sqxiFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIyRg1t+W+1gPPjc8RCjAAejEg9vwk2WCCHW xLLiytxDjBIczEoivH9d2SKEeFMSK6tSi/Lji0pzUosPMUpzsCiJ85qtvB8uJJCeWJKanZpa kFoEk2Xi4JRqYGzZvNClfILCPk6eSoNG76rE44GeC3faVh0xsNuyl1fGj2fNr5qLmxTN/Ryt nskerUnRqZRuODK9silEwOTiyevTmyTrRWKnnNfN+2KUK7W8ZmF3wiHH3Y7JTrIL7K9tbj+4 irdyp9Def3HK9wy8eyZyXungmq3EaXt6583/tiHtL98uldjFo8RSnJFoqMVcVJwIAGk9g+mN AgAA Archived-At: Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 16:16:31 -0000 Hi, >I think we can address any remaining comments as part of IETF Last Call. NO.=20 We shall forward a document we are ok with. There most likely will be other= issues and comments during IETF last call. Regards, Christer At 12:02 PM +0000 10/18/16, Ivo Sedlacek wrote: > Hello, > > first of all, I am participating in 3GPP CT1 meeting this week and I=20 > have not have time to review changes between -015 and -018 properly.=20 > Can we shift the deadline to next week? > > I am OK with resolution of ISSUE 1, ISSUE 3, ISSUE 8, ISSUE 13, ISSUE=20 > 15, ISSUE 16, ISSUE 17, ISSUE 19. > > On the remaining issues: > >> > ISSUE 2: >> > >> > section 3 - level of technical detail of the last paragraph of >=20 >> section 3 does not fit with level of technical detail of the=20 >> remaining > text of section 3. >> >> Intermediate paragraphs were added in version 17. > > I still believe that section 3 contains different types of information: > Type1: generic overview of the eCall requirements, existing solutions, .= .. > Type2: information about the draft > > It would be better to split those to separate sections. Can you elaborate on what the problem is? > >> > ISSUE 4: >> > >> > section 4, " This document registers the 'application/ >> > emergencyCallData.eCall.MSD+per' MIME Content-Type to enable the = MSD >> > to be carried in SIP." >> > >> > There is no MIME Content-Type registry. "MIME Content-Type" ->=20 >> "MIME type" >> > >> > Same in other places of the document. >> >> Corrected "content type" to "media type". > > I can still see a few occurences of "content type" in -018 - e.g. Thanks, I'll do a grep. > > --------- > Security considerations: This ****content type**** is designed to = carry > vehicle and incident-related data during an emergency call. This > data contains personal information including vehicle VIN, > location, direction, etc. Appropriate precautions need to be > taken to limit unauthorized access, inappropriate disclosure to > third parties, and eavesdropping of this information. In general, > it is acceptable for the data to be unprotected while briefly in > transit within the Mobile Network Operator (MNO); the MNO is > trusted to not permit the data to be accessed by third parties. > Sections 7 and Section 8 of [RFC7852] contain more discussion. > --------- > and > --------- > The metadata/control block is designed for use with pan-European > eCall and also eCall-like systems (i.e., in other regions), and has > extension points. Note that eCall-like systems might define their > own vehicle data blocks, and so might need to register a new INFO > package to accomodate the new data ****content type**** and the metad= ata/ > control object. > --------- > and > -------- > This ****content type**** carries metadata and control=20 > information and > requests, such as from a Public Safety Answering Point (PSAP) > to an In-Vehicle System (IVS) during an emergency call. > -------- > >> > ISSUE 6: >> > >> > section 6 - "An MSD or a metadata/control block is always=20 >> enclosed in > a multipart >> > body part (even if it would otherwise be the only body part in th= e >> > SIP message)." - which multipart MIME type is meant? >> > multipart/mixed or multipart/alternative or .... >> >> We do not need to specify that in this text. > > IMO, we need to. Else, the UA can provide multipart/mixed while PSAP=20 > expects multipart/alternative. It would be hard to imagine a use case where a UA generates multipart/alter= native. However, I don't mind adding text clarifying that multipart/mixed = is expected. > >> > ISSUE 7 >> > >> > section 6 - "The IVS then attaches an updated MSD to a SIP >> > INFO request and sends it within the dialog." - what is meant by >> > "attaching MSD to SIP INFO request"? >> >> I think that's made abundantly clear in the multiple earlier=20 >> instances in the >> same section that say "as a MIME body part". > > I do not really know what "attach body to SIP request" means.=20 > Likely, other readers will not know it either. > > A reference to a section defining how to "attach body to SIP=20 > request" would help. It's the same section, just a little bit before. > > >> > ISSUE 9 >> > >> > section 9 - what is "SIP status message"? >> >> I do not see "SIP status message" anywhere in the document. > > It was in -015 section 9 but it looks like it was already resolved in -1= 8. > > >> > ISSUE 10 >> > >> > " >> > For >> > example, if a PSAP is unable to accept an eCall (e.g., due to >> > overload or too many calls from the same location), it can reject= the >> > INVITE. Since a metadata/control object is also included in the = SIP >> > response that rejects the call, the IVS knows if the PSAP receive= d >> > the MSD, and can inform the vehicle occupants that the PSAP >> > successfully received the vehicle location and information but ca= n't >> > talk to the occupants at that time." - this prevents persons in >> > the car from getting emergency service of the PSAP using other means >> > (e.g. using circuit switched network). Possibility for DOS attack. >> >> If the PSAP is overloaded (e.g., there is a very large multi-vehicle >> incident, or another large-scale emergency incident), then there are li= kely >> to be multiple simultaneous eCall attempts. The document does not=20 >> in any way >> dictate or mandate PSAP response. PSAPs are free to respond as=20 >> they choose.=20 >> E.g., a PSAP can accept eCalls and add them to a queue, a PSAP can reje= ct an >> eCall and include an ack with "received=3Dfalse", a PSAP can reject an = eCall >> and include an ack with "received=3Dtrue". Doing the latter=20 >> indicates that the >> PSAP has received the MSD and hence is aware of the incident. > > How can the UA be sure that such response was sent by PSAP and not=20 > by an attacker, located somewhere between UA and PSAP? > > Any SIP entity which happens to be in the path of the emergency=20 > call INVITE request can generate a 600 (Busy Everywhere), 486=20 > (Busy Here), and 603 (Decline) response and populate it with a=20 > particular body. > > It is at least a security risk and it needs to be documented. OK, I'll add some text. > >> > ISSUE 11 >> > >> > "The body for an emergencyCallData.eCall.MSD info package is a >> > multipart body." - which multipart MIME type is meant? >> > multipart/mixed or multipart/alternative or .... >> >> We do not need to get into that level of detail in this text. > > IMO, we need to. Else, the UA can provide multipart/mixed while=20 > PSAP expects multipart/alternative. Same answer as above. > >> > ISSUE 14 >> > >> > "while others can be >> > expected to carry an occasional request" - meaning of "occasional= " >> > can be whatever, it depends on perspective of the user >> > - once per milisecond, once per second, once per minute, once per hou= r >> > or once per day? >> >> Other text makes it clear that a request for an updated MSD is=20 >> generally sent >> upon manual request of a PSAP call taker who suspects vehicle=20 >> state may have changed. > > A statement that the request is expected to be triggered by manual=20 > action of the PSAP call taker is good, so I suggest to add it to=20 > this section too as expert reviewer will read it. OK, I'll add text. > >> > >> > ISSUE 18 >> > >> > Accept in Figure 10 is not correct - INFO response is not expected >> > to contain body. >> >> Fixed, thanks for catching this. > > in -18, I can still see Accept with multipart/mixed in the INFO=20 > request in Figure 10. I don't see it. Here is Figure 10: INFO sip:+13145551111@example.com SIP/2.0 To: ;tag=3D9fxced76sl From: Exemplar PSAP ;tag=3D8gydfe65t0 Call-ID: 3848276298220188511@atlanta.example.com Call-Info: ; purpose=3DemergencyCallData.control CSeq: 41862 INFO Info-Package: emergencyCallData.eCall.MSD Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, SUBSCRIBE, NOTIFY, UPDATE Content-Type: multipart/mixed; boundary=3DboundaryZZZ Content-Dispositio: Info-Package Content-Length: ... --boundaryZZZ Content-Disposition: by-reference Content-Type: application/emergencyCallData.control+xml Content-ID: <3456789012@atlanta.example.com> --boundaryZZZ-- Figure 10: INFO requesting MSD > > IMO, this is wrong as we do NOT expect a body in INFO response.=20 > Yes, there will be a body in subsequent INFO request sent in=20 > opposite direction, but that's not impacted by Accept in first INFO=20 > request. > >> > >> > ISSUE 20 >> > >> > examples contain a value of schemaLocation parameter which is not >> > aligned with https://www.w3.org/TR/xmlschema-0/#schemaLocation >> > stating "The schemaLocation attribute value consists of one or more >> > pairs of URI references, separated by white space. " >> > >> > xsi:schemaLocation=3D >> > "urn:ietf:params:xml:ns:EmergencyCallData:control" >> >> Fixed. > > I can see in -18, that you chose to remove the information about=20 > schema location from the XML examples. > That's OK with me. > > However, then you can also remove the following as it is not needed any = more > > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" I've asked Hannes to verify the XML schema and examples as part of=20 IETF Last Call. --=20 Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Question Authority. They usually know where the bathroom is. --MTV's 'Daria' _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Tue Oct 18 09:43:13 2016 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 24B391296EA for ; Tue, 18 Oct 2016 09:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 WY5nN1su4xca for ; Tue, 18 Oct 2016 09:43:09 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 3C9661296CF for ; Tue, 18 Oct 2016 09:43:09 -0700 (PDT) X-AuditID: c1b4fb30-b73ff70000000cb2-92-5806511a748c Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 0A.F4.03250.A1156085; Tue, 18 Oct 2016 18:43:07 +0200 (CEST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 18 Oct 2016 18:43:06 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HFB7FKojRtrZJb1+2J6KNekO/3BlRjryAIPZ/7pfMU0=; b=HNjHXmTWHp/x3dxf4qUBgj65SUXD9dKQcnTzWzCSzEhuhI0mGenuG7a7s3O2SQ3iAORMy+51wQO6JL15mCPfAVzG6MvQA1CRZCzYRm4gR4T+bpOcjTO7DJrbdvO9cXk/fE5LRWBg9aQ1o5Hec5jB/GGTcm5kr5ou7RWdx3aalMc= Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) by AM5PR0701MB2467.eurprd07.prod.outlook.com (10.169.153.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.5; Tue, 18 Oct 2016 16:43:04 +0000 Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com ([10.169.153.136]) by AM5PR0701MB2468.eurprd07.prod.outlook.com ([10.169.153.136]) with mapi id 15.01.0679.006; Tue, 18 Oct 2016 16:43:04 +0000 From: Ivo Sedlacek To: Randall Gellens , Az Mankin , "ecrit@ietf.org" Thread-Topic: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 Thread-Index: AQHSKM9jDqYN1mg4ykGyzqHQEQ3RAqCuYzmdgAAIVlA= Date: Tue, 18 Oct 2016 16:43:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ivo.sedlacek@ericsson.com; x-originating-ip: [220.173.138.14] x-ms-office365-filtering-correlation-id: 2c5678e7-1032-43e3-a627-08d3f775d52b x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2467; 7:gXR/fuvu38KNQTYWJKKeO+Z2vtaaR/WFkfzwtWvYxScNWP0GD5sLrdSJKh0nrbUE3T9ABr7LMmkThu9yjPbO/I/PCto1A6PahF4AcEMqM1E5o/2MbhmdO+YcmjgcuhL6ZOZN+5+HgrfAOXjLOZ1AkrsNPNgmpZ0/CRgzZYZOtcUHsljgEpeoE2oL3QeFB1MMkrON6uHnAJgHb+IpLkoJsiRmuJWKKewXGBH7qDVUZXdHQH57hFQhTLByzAWTvkFJ+vm5pZgFHOXViEtNmH7gePWCCPaCQ/3ovH7Xv+fzIW0CsridRrOieSF64A2HWeuysfLIG60q6tRNDU+BacWa1w4Twf4/I1sSKnvyZb7qtN8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0701MB2467; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AM5PR0701MB2467; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2467; x-forefront-prvs: 00997889E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(13464003)(377454003)(51444003)(199003)(189002)(7696004)(2950100002)(122556002)(5002640100001)(10400500002)(5660300001)(66066001)(5001770100001)(97736004)(54356999)(101416001)(189998001)(76176999)(50986999)(33656002)(2501003)(5890100001)(2906002)(107886002)(9686002)(86362001)(2900100001)(8936002)(586003)(87936001)(106356001)(305945005)(74316002)(7846002)(93886004)(76576001)(11100500001)(105586002)(106116001)(6116002)(102836003)(230783001)(8676002)(77096005)(3660700001)(3846002)(81166006)(81156014)(15975445007)(68736007)(92566002)(7736002)(19580395003)(19580405001)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2467; H:AM5PR0701MB2468.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2016 16:43:04.7572 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2467 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0iTURjGOd9l+1wOTkvzxRnEyMS8ZGImUrb+W4Sm0UWk0JlfaumUfVPS qOxGOcmKJeTosmwliVJOxUxNXUpamqEhGUqkk2leEg28JJnbWdB/v/M+z/ue8z4cjpYVs95c ukbHazXqDIVIwpTG14cHyeNE8SEf5vwinpY0UBGXysbYiAW7HilpVYNxWKwym5coVd3QKBNL J0h2p/AZ6bm8dntUkiSt+XK/KPvtkbO9pmWqAI0p9ciNAxwGjSUTlB5JOBl+gWB6skJMDp0I 7tXYaIeLwTdp6GmKIsIDCuYfXnW1dCOomxyhHC4RDoY7te2sHnGcB9bBR8NhR3kD3guPLD8Y B3tgJYzp28XEEgnvFmRkvi+sGJeRg6U4CTqnBhAZ30bD67pW1iG4rT3V8LPaeRXCG2HhfaWT aewFX22PKLIOBnNTL03YEyZG/7DEfxxWi+ZZUlfAYk2piHA0dE8sMoTLaJhewoRV8GWxzzUz C1rKBl2eA1BktDkTAtyEYGRwGBHBB8p/3WKIYBLBSLPN2S3DPJRXXUMkCW8Y/lzoYh8YH2pm byN/439LEA4EU+OciHAAPHs8SRudyayHrlIbY0JMBfIUeCE5MzU0NJjXpp8UhCxNsIbXWdDa L2mr/R3yCk3Y91kR5pDCXZo0yMTLWHWukJdpRcDRCg9p8kFRvEyaos7L57VZidqcDF6wIjnH KLyk4c+/HZPhVLWOP8Pz2bz2n0pxbt4FyKeorVg+46UMbf00HhidP3nK9zz28d50Ijj2bswM NRt0YzXGlOfXbbnQcrpyS5zJcH326HipPd0gCO5X3qQmn8vpn3q581CPfyEfNrbypL5LHKO5 n2itChil9kTur+Y6JJtnxB1b5doG6y6rub5R6Gu1R+Gui5Z1fQUJA/zQdwUjpKl3bKO1gvov 51qDcSEDAAA= Archived-At: Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 16:43:12 -0000 The comments were submitted as part of WGLC and I expect them to be address= ed during WGLC. Kind regards Ivo -----Original Message----- From: Randall Gellens [mailto:rg+ietf@randy.pensive.org]=20 Sent: Wednesday, October 19, 2016 12:12 AM To: Ivo Sedlacek ; Az Mankin ; ecrit@ietf.org Subject: RE: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 Hi Ivo, I think we can address any remaining comments as part of IETF Last Call. --Randy At 12:02 PM +0000 10/18/16, Ivo Sedlacek wrote: > Hello, > > first of all, I am participating in 3GPP CT1 meeting this week and I=20 > have not have time to review changes between -015 and -018 properly.=20 > Can we shift the deadline to next week? > > I am OK with resolution of ISSUE 1, ISSUE 3, ISSUE 8, ISSUE 13, ISSUE=20 > 15, ISSUE 16, ISSUE 17, ISSUE 19. > > On the remaining issues: > >> > ISSUE 2: >> > >> > section 3 - level of technical detail of the last paragraph of >=20 >> section 3 does not fit with level of technical detail of the=20 >> remaining > text of section 3. >> >> Intermediate paragraphs were added in version 17. > > I still believe that section 3 contains different types of information: > Type1: generic overview of the eCall requirements, existing solutions, .= .. > Type2: information about the draft > > It would be better to split those to separate sections. Can you elaborate on what the problem is? > >> > ISSUE 4: >> > >> > section 4, " This document registers the 'application/ >> > emergencyCallData.eCall.MSD+per' MIME Content-Type to enable the = MSD >> > to be carried in SIP." >> > >> > There is no MIME Content-Type registry. "MIME Content-Type" ->=20 >> "MIME type" >> > >> > Same in other places of the document. >> >> Corrected "content type" to "media type". > > I can still see a few occurences of "content type" in -018 - e.g. Thanks, I'll do a grep. > > --------- > Security considerations: This ****content type**** is designed to = carry > vehicle and incident-related data during an emergency call. This > data contains personal information including vehicle VIN, > location, direction, etc. Appropriate precautions need to be > taken to limit unauthorized access, inappropriate disclosure to > third parties, and eavesdropping of this information. In general, > it is acceptable for the data to be unprotected while briefly in > transit within the Mobile Network Operator (MNO); the MNO is > trusted to not permit the data to be accessed by third parties. > Sections 7 and Section 8 of [RFC7852] contain more discussion. > --------- > and > --------- > The metadata/control block is designed for use with pan-European > eCall and also eCall-like systems (i.e., in other regions), and has > extension points. Note that eCall-like systems might define their > own vehicle data blocks, and so might need to register a new INFO > package to accomodate the new data ****content type**** and the metad= ata/ > control object. > --------- > and > -------- > This ****content type**** carries metadata and control=20 > information and > requests, such as from a Public Safety Answering Point (PSAP) > to an In-Vehicle System (IVS) during an emergency call. > -------- > >> > ISSUE 6: >> > >> > section 6 - "An MSD or a metadata/control block is always=20 >> enclosed in > a multipart >> > body part (even if it would otherwise be the only body part in th= e >> > SIP message)." - which multipart MIME type is meant? >> > multipart/mixed or multipart/alternative or .... >> >> We do not need to specify that in this text. > > IMO, we need to. Else, the UA can provide multipart/mixed while PSAP=20 > expects multipart/alternative. It would be hard to imagine a use case where a UA generates multipart/alter= native. However, I don't mind adding text clarifying that multipart/mixed = is expected. > >> > ISSUE 7 >> > >> > section 6 - "The IVS then attaches an updated MSD to a SIP >> > INFO request and sends it within the dialog." - what is meant by >> > "attaching MSD to SIP INFO request"? >> >> I think that's made abundantly clear in the multiple earlier=20 >> instances in the >> same section that say "as a MIME body part". > > I do not really know what "attach body to SIP request" means.=20 > Likely, other readers will not know it either. > > A reference to a section defining how to "attach body to SIP=20 > request" would help. It's the same section, just a little bit before. > > >> > ISSUE 9 >> > >> > section 9 - what is "SIP status message"? >> >> I do not see "SIP status message" anywhere in the document. > > It was in -015 section 9 but it looks like it was already resolved in -1= 8. > > >> > ISSUE 10 >> > >> > " >> > For >> > example, if a PSAP is unable to accept an eCall (e.g., due to >> > overload or too many calls from the same location), it can reject= the >> > INVITE. Since a metadata/control object is also included in the = SIP >> > response that rejects the call, the IVS knows if the PSAP receive= d >> > the MSD, and can inform the vehicle occupants that the PSAP >> > successfully received the vehicle location and information but ca= n't >> > talk to the occupants at that time." - this prevents persons in >> > the car from getting emergency service of the PSAP using other means >> > (e.g. using circuit switched network). Possibility for DOS attack. >> >> If the PSAP is overloaded (e.g., there is a very large multi-vehicle >> incident, or another large-scale emergency incident), then there are li= kely >> to be multiple simultaneous eCall attempts. The document does not=20 >> in any way >> dictate or mandate PSAP response. PSAPs are free to respond as=20 >> they choose.=20 >> E.g., a PSAP can accept eCalls and add them to a queue, a PSAP can reje= ct an >> eCall and include an ack with "received=3Dfalse", a PSAP can reject an = eCall >> and include an ack with "received=3Dtrue". Doing the latter=20 >> indicates that the >> PSAP has received the MSD and hence is aware of the incident. > > How can the UA be sure that such response was sent by PSAP and not=20 > by an attacker, located somewhere between UA and PSAP? > > Any SIP entity which happens to be in the path of the emergency=20 > call INVITE request can generate a 600 (Busy Everywhere), 486=20 > (Busy Here), and 603 (Decline) response and populate it with a=20 > particular body. > > It is at least a security risk and it needs to be documented. OK, I'll add some text. > >> > ISSUE 11 >> > >> > "The body for an emergencyCallData.eCall.MSD info package is a >> > multipart body." - which multipart MIME type is meant? >> > multipart/mixed or multipart/alternative or .... >> >> We do not need to get into that level of detail in this text. > > IMO, we need to. Else, the UA can provide multipart/mixed while=20 > PSAP expects multipart/alternative. Same answer as above. > >> > ISSUE 14 >> > >> > "while others can be >> > expected to carry an occasional request" - meaning of "occasional= " >> > can be whatever, it depends on perspective of the user >> > - once per milisecond, once per second, once per minute, once per hou= r >> > or once per day? >> >> Other text makes it clear that a request for an updated MSD is=20 >> generally sent >> upon manual request of a PSAP call taker who suspects vehicle=20 >> state may have changed. > > A statement that the request is expected to be triggered by manual=20 > action of the PSAP call taker is good, so I suggest to add it to=20 > this section too as expert reviewer will read it. OK, I'll add text. > >> > >> > ISSUE 18 >> > >> > Accept in Figure 10 is not correct - INFO response is not expected >> > to contain body. >> >> Fixed, thanks for catching this. > > in -18, I can still see Accept with multipart/mixed in the INFO=20 > request in Figure 10. I don't see it. Here is Figure 10: INFO sip:+13145551111@example.com SIP/2.0 To: ;tag=3D9fxced76sl From: Exemplar PSAP ;tag=3D8gydfe65t0 Call-ID: 3848276298220188511@atlanta.example.com Call-Info: ; purpose=3DemergencyCallData.control CSeq: 41862 INFO Info-Package: emergencyCallData.eCall.MSD Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, SUBSCRIBE, NOTIFY, UPDATE Content-Type: multipart/mixed; boundary=3DboundaryZZZ Content-Dispositio: Info-Package Content-Length: ... --boundaryZZZ Content-Disposition: by-reference Content-Type: application/emergencyCallData.control+xml Content-ID: <3456789012@atlanta.example.com> --boundaryZZZ-- Figure 10: INFO requesting MSD > > IMO, this is wrong as we do NOT expect a body in INFO response.=20 > Yes, there will be a body in subsequent INFO request sent in=20 > opposite direction, but that's not impacted by Accept in first INFO=20 > request. > >> > >> > ISSUE 20 >> > >> > examples contain a value of schemaLocation parameter which is not >> > aligned with https://www.w3.org/TR/xmlschema-0/#schemaLocation >> > stating "The schemaLocation attribute value consists of one or more >> > pairs of URI references, separated by white space. " >> > >> > xsi:schemaLocation=3D >> > "urn:ietf:params:xml:ns:EmergencyCallData:control" >> >> Fixed. > > I can see in -18, that you chose to remove the information about=20 > schema location from the XML examples. > That's OK with me. > > However, then you can also remove the following as it is not needed any = more > > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" I've asked Hannes to verify the XML schema and examples as part of=20 IETF Last Call. --=20 Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Question Authority. They usually know where the bathroom is. --MTV's 'Daria' From nobody Tue Oct 18 10:35:34 2016 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 CD2001296FD; Tue, 18 Oct 2016 10:35:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147681213283.30754.15218226373073144841.idtracker@ietfa.amsl.com> Date: Tue, 18 Oct 2016 10:35:32 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-19.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:35:33 -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 of the IETF. Title : Next-Generation Pan-European eCall Authors : Randall Gellens Hannes Tschofenig Filename : draft-ietf-ecrit-ecall-19.txt Pages : 45 Date : 2016-10-18 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of the pan European in- vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles, providing real-time communications and an integrated set of related data. This document also registers MIME media types and an Emergency Call Additional Data Block for the eCall vehicle data and metadata/control data, and an INFO package to enable carrying this data in INFO requests. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-ecall-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-19 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 Tue Oct 18 10:35:55 2016 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 CC9E3129785; Tue, 18 Oct 2016 10:35:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147681214483.30730.5167219890178885223.idtracker@ietfa.amsl.com> Date: Tue, 18 Oct 2016 10:35:44 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-18.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:35:45 -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 of the IETF. Title : Next-Generation Vehicle-Initiated Emergency Calls Authors : Randall Gellens Brian Rosen Hannes Tschofenig Filename : draft-ietf-ecrit-car-crash-18.txt Pages : 43 Date : 2016-10-18 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data. This document also registers a MIME media type and Emergency Call Additional Data Block for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash) and an INFO package to enable carrying this and related data in INFO requests. An external specification for the data format, contents, and structure are referenced in this document. This document reuses the technical aspects of next-generation pan- European eCall (a mandated and standardized system for emergency calls by in-vehicle systems within Europe and other regions). However, this document specifies a different set of vehicle (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This document is an extension of the eCall document, with the primary differences being that this document makes the MSD data set optional and VEDS mandatory, and adds attribute values to the metadata/control object to permit greater functionality. This document registers a new INFO package (identical to that registered for eCall but with the addition of the VEDS MIME type). This document also describes legacy (circuit-switched) ACN systems and their migration to next-generation emergency calling, to provide background information and context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-18 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 Tue Oct 18 10:37:07 2016 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 8DD1B129785 for ; Tue, 18 Oct 2016 10:37:05 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 VTzJUgpCvlD1 for ; Tue, 18 Oct 2016 10:37:03 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0566D12973E for ; Tue, 18 Oct 2016 10:36:25 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 18 Oct 2016 10:36:24 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Tue, 18 Oct 2016 10:36:22 -0700 To: Ivo Sedlacek , Az Mankin , "ecrit@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:37:05 -0000 Hi Ivo and Christer, All comments have been addressed in -19. Thank you. At 4:43 PM +0000 10/18/16, Ivo Sedlacek wrote: > The comments were submitted as part of WGLC and I expect them to be > addressed during WGLC. > > Kind regards > > Ivo > > -----Original Message----- > From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] > Sent: Wednesday, October 19, 2016 12:12 AM > To: Ivo Sedlacek ; Az Mankin > ; ecrit@ietf.org > Subject: RE: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 > > Hi Ivo, > > I think we can address any remaining comments as part of IETF Last Call. > > --Randy > > At 12:02 PM +0000 10/18/16, Ivo Sedlacek wrote: > >> Hello, >> >> first of all, I am participating in 3GPP CT1 meeting this week and I >> have not have time to review changes between -015 and -018 properly. >> Can we shift the deadline to next week? >> >> I am OK with resolution of ISSUE 1, ISSUE 3, ISSUE 8, ISSUE 13, ISSUE >> 15, ISSUE 16, ISSUE 17, ISSUE 19. >> >> On the remaining issues: >> >>> > ISSUE 2: >>> > >>> > section 3 - level of technical detail of the last paragraph of > >>> section 3 does not fit with level of technical detail of the >>> remaining > text of section 3. >>> >>> Intermediate paragraphs were added in version 17. >> >> I still believe that section 3 contains different types of information: >> Type1: generic overview of the eCall requirements, existing solutions, ... >> Type2: information about the draft >> >> It would be better to split those to separate sections. > > Can you elaborate on what the problem is? > >> >>> > ISSUE 4: >>> > >>> > section 4, " This document registers the 'application/ >>> > emergencyCallData.eCall.MSD+per' MIME Content-Type to enable the MSD >>> > to be carried in SIP." >>> > >>> > There is no MIME Content-Type registry. "MIME Content-Type" -> >>> "MIME type" >>> > >>> > Same in other places of the document. >>> >>> Corrected "content type" to "media type". >> >> I can still see a few occurences of "content type" in -018 - e.g. > > Thanks, I'll do a grep. > >> >> --------- >> Security considerations: This ****content type**** is >> designed to carry >> vehicle and incident-related data during an emergency call. This >> data contains personal information including vehicle VIN, >> location, direction, etc. Appropriate precautions need to be >> taken to limit unauthorized access, inappropriate disclosure to >> third parties, and eavesdropping of this information. In general, >> it is acceptable for the data to be unprotected while briefly in >> transit within the Mobile Network Operator (MNO); the MNO is >> trusted to not permit the data to be accessed by third parties. >> Sections 7 and Section 8 of [RFC7852] contain more discussion. >> --------- >> and >> --------- >> The metadata/control block is designed for use with pan-European >> eCall and also eCall-like systems (i.e., in other regions), and has >> extension points. Note that eCall-like systems might define their >> own vehicle data blocks, and so might need to register a new INFO >> package to accomodate the new data ****content type**** and >> the metadata/ >> control object. >> --------- >> and >> -------- >> This ****content type**** carries metadata and control >> information and >> requests, such as from a Public Safety Answering Point (PSAP) >> to an In-Vehicle System (IVS) during an emergency call. >> -------- >> >>> > ISSUE 6: >>> > >>> > section 6 - "An MSD or a metadata/control block is always >>> enclosed in > a multipart >>> > body part (even if it would otherwise be the only body part in the >>> > SIP message)." - which multipart MIME type is meant? >>> > multipart/mixed or multipart/alternative or .... >>> >>> We do not need to specify that in this text. > > >> IMO, we need to. Else, the UA can provide multipart/mixed while PSAP >> expects multipart/alternative. > > It would be hard to imagine a use case where a UA generates > multipart/alternative. However, I don't mind adding text > clarifying that multipart/mixed is expected. > >> >>> > ISSUE 7 >>> > >>> > section 6 - "The IVS then attaches an updated MSD to a SIP >>> > INFO request and sends it within the dialog." - what is meant by >>> > "attaching MSD to SIP INFO request"? >>> >>> I think that's made abundantly clear in the multiple earlier >>> instances in the >>> same section that say "as a MIME body part". >> >> I do not really know what "attach body to SIP request" means. >> Likely, other readers will not know it either. >> >> A reference to a section defining how to "attach body to SIP >> request" would help. > > It's the same section, just a little bit before. > >> >> >>> > ISSUE 9 >>> > >>> > section 9 - what is "SIP status message"? >>> >>> I do not see "SIP status message" anywhere in the document. >> >> It was in -015 section 9 but it looks like it was already resolved in -18. >> >> >>> > ISSUE 10 >>> > >>> > " >>> > For >>> > example, if a PSAP is unable to accept an eCall (e.g., due to >>> > overload or too many calls from the same location), it can >>> reject the >>> > INVITE. Since a metadata/control object is also included in the SIP >>> > response that rejects the call, the IVS knows if the PSAP received >>> > the MSD, and can inform the vehicle occupants that the PSAP >>> > successfully received the vehicle location and information but can't >>> > talk to the occupants at that time." - this prevents persons in >>> > the car from getting emergency service of the PSAP using other means >>> > (e.g. using circuit switched network). Possibility for DOS attack. >>> >>> If the PSAP is overloaded (e.g., there is a very large multi-vehicle >>> incident, or another large-scale emergency incident), then there >>> are likely >>> to be multiple simultaneous eCall attempts. The document does not >>> in any way >>> dictate or mandate PSAP response. PSAPs are free to respond as >>> they choose. >>> E.g., a PSAP can accept eCalls and add them to a queue, a PSAP >>> can reject an >>> eCall and include an ack with "received=false", a PSAP can reject an eCall >>> and include an ack with "received=true". Doing the latter >>> indicates that the >>> PSAP has received the MSD and hence is aware of the incident. >> >> How can the UA be sure that such response was sent by PSAP and not >> by an attacker, located somewhere between UA and PSAP? >> >> Any SIP entity which happens to be in the path of the emergency >> call INVITE request can generate a 600 (Busy Everywhere), 486 >> (Busy Here), and 603 (Decline) response and populate it with a >> particular body. >> >> It is at least a security risk and it needs to be documented. > > OK, I'll add some text. > >> >>> > ISSUE 11 >>> > >>> > "The body for an emergencyCallData.eCall.MSD info package is a >>> > multipart body." - which multipart MIME type is meant? >>> > multipart/mixed or multipart/alternative or .... >>> >>> We do not need to get into that level of detail in this text. >> >> IMO, we need to. Else, the UA can provide multipart/mixed while >> PSAP expects multipart/alternative. > > Same answer as above. > >> >>> > ISSUE 14 >>> > >>> > "while others can be >>> > expected to carry an occasional request" - meaning of "occasional" >>> > can be whatever, it depends on perspective of the user >>> > - once per milisecond, once per second, once per minute, once per hour >>> > or once per day? >>> >>> Other text makes it clear that a request for an updated MSD is >>> generally sent >>> upon manual request of a PSAP call taker who suspects vehicle >>> state may have changed. >> >> A statement that the request is expected to be triggered by manual >> action of the PSAP call taker is good, so I suggest to add it to >> this section too as expert reviewer will read it. > > OK, I'll add text. > >> >>> > >>> > ISSUE 18 >>> > >>> > Accept in Figure 10 is not correct - INFO response is not expected >>> > to contain body. > >> >>> Fixed, thanks for catching this. >> >> in -18, I can still see Accept with multipart/mixed in the INFO >> request in Figure 10. > > I don't see it. Here is Figure 10: > > INFO sip:+13145551111@example.com SIP/2.0 > To: ;tag=9fxced76sl > From: Exemplar PSAP ;tag=8gydfe65t0 > Call-ID: 3848276298220188511@atlanta.example.com > Call-Info: ; > purpose=emergencyCallData.control > CSeq: 41862 INFO > Info-Package: emergencyCallData.eCall.MSD > Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, > SUBSCRIBE, NOTIFY, UPDATE > Content-Type: multipart/mixed; boundary=boundaryZZZ > Content-Dispositio: Info-Package > Content-Length: ... > > --boundaryZZZ > Content-Disposition: by-reference > Content-Type: application/emergencyCallData.control+xml > Content-ID: <3456789012@atlanta.example.com> > > > xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> > > > > > --boundaryZZZ-- > > Figure 10: INFO requesting MSD > > > > >> >> IMO, this is wrong as we do NOT expect a body in INFO response. >> Yes, there will be a body in subsequent INFO request sent in >> opposite direction, but that's not impacted by Accept in first INFO >> request. >> >>> > >>> > ISSUE 20 >>> > >>> > examples contain a value of schemaLocation parameter which is not >>> > aligned with https://www.w3.org/TR/xmlschema-0/#schemaLocation >>> > stating "The schemaLocation attribute value consists of one or more >>> > pairs of URI references, separated by white space. " >>> > >>> > xsi:schemaLocation= >>> > "urn:ietf:params:xml:ns:EmergencyCallData:control" >>> >>> Fixed. >> >> I can see in -18, that you chose to remove the information about >> schema location from the XML examples. >> That's OK with me. >> >> However, then you can also remove the following as it is not >> needed any more >> >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > > I've asked Hannes to verify the XML schema and examples as part of > IETF Last Call. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > Question Authority. They usually know where the bathroom is. > --MTV's 'Daria' -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- It's a good idea to obey all the rules when you're young just so you'll have the strength to break them when you're old. --Mark Twain From nobody Tue Oct 18 10:37:35 2016 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 119981296FD for ; Tue, 18 Oct 2016 10:37:33 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 hIMIVA8d2Htx for ; Tue, 18 Oct 2016 10:37:30 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 05DBE129762 for ; Tue, 18 Oct 2016 10:37:04 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 18 Oct 2016 10:37:03 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <147646451751.18604.4638966497289572815.idtracker@ietfa.amsl.com> <147646453871.18548.7812739569679702499.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Tue, 18 Oct 2016 10:37:02 -0700 To: Az Mankin , Christer Holmberg , Ivo Sedlacek From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-18.txt and draft-ietf-ecrit-car-crash-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:37:33 -0000 eCall-19 and car-crash-18 (just uploaded now) address all comments. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I really don't know one plane from the other. To me they are just marginal costs with wings. --Alfred Kahn, "Father of Airline Deregulation," 1977 From nobody Tue Oct 18 10:53:10 2016 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 ABEB3129712 for ; Tue, 18 Oct 2016 10:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Bl9lBlC5VdRV for ; Tue, 18 Oct 2016 10:53:05 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 BA703129404 for ; Tue, 18 Oct 2016 10:53:05 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id d132so1518065oib.2 for ; Tue, 18 Oct 2016 10:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hrjL2om7aR2UyDeR479DYFQFXmJA8NSkQxTaeT4G1dI=; b=iw09a3v8w2Ka5YO1PbcJmMEu6vl79AJSfnpb+RP44c3RKVd/l6lmnElq39ZcmZZIHH wW/2jokhWEFCOdEIBS0U1/As9Iv7a9YrJVCplHOCkUY+5e9iZZu7RQ/tKAJ63p0q00H+ yuAzv4cXSnHwLoyUq+GnjFPzinh7f3/YpnQEa0l6SjgAtBwArJHc1J4aKXuGODvqvIw1 FaF0y8M+c1oP39votAs5M/sEF2J94wICFABiyqkUu/9leB39AWjfOADHwxmPajVmJlH4 4whOYSN67hRiXVEY13sNX+GxGwaOKEtuFpNfWBBC8xhGqx1z9V8RSo61KQUaJjrIavIG nFEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hrjL2om7aR2UyDeR479DYFQFXmJA8NSkQxTaeT4G1dI=; b=SeXO2ct7fRqagBdeDH3BKYRY+SIWqLANr7CMiS5ZmWUzKMjtEMNsEroL/VheLyUV/J 0pTbmO9bIH40ssCMd9XVe2ZuTA6iTMZ2qzFLibNTEnEsj0Z1h18DxGevD2HqeDNixSYG bDx8y+aZ+LB0KmqBtfQLlHB9Xi0UqqLK6MegbRqOeWnnkKSrZAtwFA37nFGjwre6gIxi 4zMlkhAgLZ03zwi8VVdhBc7fQUX/9vjBPi9xR9ztpnlwmnUScphvL3UbLHLrPAEAUhjf WNmNS2+yZoU4VRDBOIsErro98IEVNfbeb3/550OZ0H6wSAaNfD9v4+KSKT1kSeE0lWsP y3GA== X-Gm-Message-State: AA6/9Rm5nAp0Zl3R1SwtsT87X9cFmcz38ho2XxjqGIgAK8Qm1PXX+G2Z29hc3GKOJOJRl/3g7Qjz5vozxkKwMQ== X-Received: by 10.157.29.37 with SMTP id m34mr1138951otm.152.1476813184885; Tue, 18 Oct 2016 10:53:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.193.136 with HTTP; Tue, 18 Oct 2016 10:53:04 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BDB34E1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BDB34E1@ESESSMB209.ericsson.se> From: Az Mankin Date: Tue, 18 Oct 2016 10:53:04 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113b99de48ee61053f275d85 Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 17:53:09 -0000 --001a113b99de48ee61053f275d85 Content-Type: text/plain; charset=UTF-8 Hi, everyone, I'd like to remind people that we use rough consensus, not perfect unanimity, and we use a well defined process, including practical time periods for our phases of last call. We also care about "running code," and one thing that would be valuable for this last day of the last call is to share info on state of implementation of these two specs. This doesn't mean they must be fully implemented and deployed, of course, but what types of pragmatic or empirical tests have occurred so far? I'm planning to request IETF Last Call this afternoon (Pacific Time) as previously announced. This will not launch an immediate IETF Last Call, because there is first an AD Review, and I will work to present to Alyssa what the remaining issues are in the shepherd's writeup. I'm open to your sending me text as input for the writeup. Allison On Tue, Oct 18, 2016 at 9:16 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >I think we can address any remaining comments as part of IETF Last Call. > > NO. > > We shall forward a document we are ok with. There most likely will be > other issues and comments during IETF last call. > > Regards, > > Christer > > > At 12:02 PM +0000 10/18/16, Ivo Sedlacek wrote: > > > Hello, > > > > first of all, I am participating in 3GPP CT1 meeting this week and I > > have not have time to review changes between -015 and -018 properly. > > Can we shift the deadline to next week? > > > > I am OK with resolution of ISSUE 1, ISSUE 3, ISSUE 8, ISSUE 13, ISSUE > > 15, ISSUE 16, ISSUE 17, ISSUE 19. > > > > On the remaining issues: > > > >> > ISSUE 2: > >> > > >> > section 3 - level of technical detail of the last paragraph of > > >> section 3 does not fit with level of technical detail of the > >> remaining > text of section 3. > >> > >> Intermediate paragraphs were added in version 17. > > > > I still believe that section 3 contains different types of information: > > Type1: generic overview of the eCall requirements, existing solutions, > ... > > Type2: information about the draft > > > > It would be better to split those to separate sections. > > Can you elaborate on what the problem is? > > > > >> > ISSUE 4: > >> > > >> > section 4, " This document registers the 'application/ > >> > emergencyCallData.eCall.MSD+per' MIME Content-Type to enable > the MSD > >> > to be carried in SIP." > >> > > >> > There is no MIME Content-Type registry. "MIME Content-Type" -> > >> "MIME type" > >> > > >> > Same in other places of the document. > >> > >> Corrected "content type" to "media type". > > > > I can still see a few occurences of "content type" in -018 - e.g. > > Thanks, I'll do a grep. > > > > > --------- > > Security considerations: This ****content type**** is designed to > carry > > vehicle and incident-related data during an emergency call. This > > data contains personal information including vehicle VIN, > > location, direction, etc. Appropriate precautions need to be > > taken to limit unauthorized access, inappropriate disclosure to > > third parties, and eavesdropping of this information. In general, > > it is acceptable for the data to be unprotected while briefly in > > transit within the Mobile Network Operator (MNO); the MNO is > > trusted to not permit the data to be accessed by third parties. > > Sections 7 and Section 8 of [RFC7852] contain more discussion. > > --------- > > and > > --------- > > The metadata/control block is designed for use with pan-European > > eCall and also eCall-like systems (i.e., in other regions), and has > > extension points. Note that eCall-like systems might define their > > own vehicle data blocks, and so might need to register a new INFO > > package to accomodate the new data ****content type**** and the > metadata/ > > control object. > > --------- > > and > > -------- > > This ****content type**** carries metadata and control > > information and > > requests, such as from a Public Safety Answering Point (PSAP) > > to an In-Vehicle System (IVS) during an emergency call. > > -------- > > > >> > ISSUE 6: > >> > > >> > section 6 - "An MSD or a metadata/control block is always > >> enclosed in > a multipart > >> > body part (even if it would otherwise be the only body part in > the > >> > SIP message)." - which multipart MIME type is meant? > >> > multipart/mixed or multipart/alternative or .... > >> > >> We do not need to specify that in this text. > > > > IMO, we need to. Else, the UA can provide multipart/mixed while PSAP > > expects multipart/alternative. > > It would be hard to imagine a use case where a UA generates > multipart/alternative. However, I don't mind adding text clarifying that > multipart/mixed is expected. > > > > >> > ISSUE 7 > >> > > >> > section 6 - "The IVS then attaches an updated MSD to a SIP > >> > INFO request and sends it within the dialog." - what is meant by > >> > "attaching MSD to SIP INFO request"? > >> > >> I think that's made abundantly clear in the multiple earlier > >> instances in the > >> same section that say "as a MIME body part". > > > > I do not really know what "attach body to SIP request" means. > > Likely, other readers will not know it either. > > > > A reference to a section defining how to "attach body to SIP > > request" would help. > > It's the same section, just a little bit before. > > > > > > >> > ISSUE 9 > >> > > >> > section 9 - what is "SIP status message"? > >> > >> I do not see "SIP status message" anywhere in the document. > > > > It was in -015 section 9 but it looks like it was already resolved in > -18. > > > > > >> > ISSUE 10 > >> > > >> > " > >> > For > >> > example, if a PSAP is unable to accept an eCall (e.g., due to > >> > overload or too many calls from the same location), it can > reject the > >> > INVITE. Since a metadata/control object is also included in the > SIP > >> > response that rejects the call, the IVS knows if the PSAP > received > >> > the MSD, and can inform the vehicle occupants that the PSAP > >> > successfully received the vehicle location and information but > can't > >> > talk to the occupants at that time." - this prevents persons in > >> > the car from getting emergency service of the PSAP using other means > >> > (e.g. using circuit switched network). Possibility for DOS attack. > >> > >> If the PSAP is overloaded (e.g., there is a very large multi-vehicle > >> incident, or another large-scale emergency incident), then there are > likely > >> to be multiple simultaneous eCall attempts. The document does not > >> in any way > >> dictate or mandate PSAP response. PSAPs are free to respond as > >> they choose. > >> E.g., a PSAP can accept eCalls and add them to a queue, a PSAP can > reject an > >> eCall and include an ack with "received=false", a PSAP can reject an > eCall > >> and include an ack with "received=true". Doing the latter > >> indicates that the > >> PSAP has received the MSD and hence is aware of the incident. > > > > How can the UA be sure that such response was sent by PSAP and not > > by an attacker, located somewhere between UA and PSAP? > > > > Any SIP entity which happens to be in the path of the emergency > > call INVITE request can generate a 600 (Busy Everywhere), 486 > > (Busy Here), and 603 (Decline) response and populate it with a > > particular body. > > > > It is at least a security risk and it needs to be documented. > > OK, I'll add some text. > > > > >> > ISSUE 11 > >> > > >> > "The body for an emergencyCallData.eCall.MSD info package is a > >> > multipart body." - which multipart MIME type is meant? > >> > multipart/mixed or multipart/alternative or .... > >> > >> We do not need to get into that level of detail in this text. > > > > IMO, we need to. Else, the UA can provide multipart/mixed while > > PSAP expects multipart/alternative. > > Same answer as above. > > > > >> > ISSUE 14 > >> > > >> > "while others can be > >> > expected to carry an occasional request" - meaning of > "occasional" > >> > can be whatever, it depends on perspective of the user > >> > - once per milisecond, once per second, once per minute, once per > hour > >> > or once per day? > >> > >> Other text makes it clear that a request for an updated MSD is > >> generally sent > >> upon manual request of a PSAP call taker who suspects vehicle > >> state may have changed. > > > > A statement that the request is expected to be triggered by manual > > action of the PSAP call taker is good, so I suggest to add it to > > this section too as expert reviewer will read it. > > OK, I'll add text. > > > > >> > > >> > ISSUE 18 > >> > > >> > Accept in Figure 10 is not correct - INFO response is not expected > >> > to contain body. > >> > >> Fixed, thanks for catching this. > > > > in -18, I can still see Accept with multipart/mixed in the INFO > > request in Figure 10. > > I don't see it. Here is Figure 10: > > INFO sip:+13145551111@example.com SIP/2.0 > To: ;tag=9fxced76sl > From: Exemplar PSAP ;tag=8gydfe65t0 > Call-ID: 3848276298220188511@atlanta.example.com > Call-Info: ; > purpose=emergencyCallData.control > CSeq: 41862 INFO > Info-Package: emergencyCallData.eCall.MSD > Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE, > SUBSCRIBE, NOTIFY, UPDATE > Content-Type: multipart/mixed; boundary=boundaryZZZ > Content-Dispositio: Info-Package > Content-Length: ... > > --boundaryZZZ > Content-Disposition: by-reference > Content-Type: application/emergencyCallData.control+xml > Content-ID: <3456789012@atlanta.example.com> > > > xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> > > > > > --boundaryZZZ-- > > Figure 10: INFO requesting MSD > > > > > > > > IMO, this is wrong as we do NOT expect a body in INFO response. > > Yes, there will be a body in subsequent INFO request sent in > > opposite direction, but that's not impacted by Accept in first INFO > > request. > > > >> > > >> > ISSUE 20 > >> > > >> > examples contain a value of schemaLocation parameter which is not > >> > aligned with https://www.w3.org/TR/xmlschema-0/#schemaLocation > >> > stating "The schemaLocation attribute value consists of one or more > >> > pairs of URI references, separated by white space. " > >> > > >> > xsi:schemaLocation= > >> > "urn:ietf:params:xml:ns:EmergencyCallData:control" > >> > >> Fixed. > > > > I can see in -18, that you chose to remove the information about > > schema location from the XML examples. > > That's OK with me. > > > > However, then you can also remove the following as it is not needed any > more > > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > > I've asked Hannes to verify the XML schema and examples as part of > IETF Last Call. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > Question Authority. They usually know where the bathroom is. > --MTV's 'Daria' > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > --001a113b99de48ee61053f275d85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, everyone,

I'd like to = remind people that we use rough consensus, not perfect unanimity, and we us= e a well defined process, including practical time periods for our phases o= f last call.=C2=A0=C2=A0 We also care about "running code," and o= ne thing that would be valuable for this last day of the last call is to sh= are info on state of implementation of these two specs.=C2=A0 This doesn= 9;t mean they must be fully implemented and deployed, of course, but what t= ypes of pragmatic or empirical tests have occurred so far?

I&= #39;m planning to request IETF Last Call this afternoon (Pacific Time) as p= reviously announced.=C2=A0 This will not launch an immediate IETF Last Call= , because there is first an AD Review, and I will work to present to Alyssa= what the remaining issues are in the shepherd's writeup.=C2=A0 I'm= open to your sending me text as input for the writeup.

A= llison





On Tue, Oc= t 18, 2016 at 9:16 AM, Christer Holmberg <christer.holmberg@e= ricsson.com> wrote:
Hi,

>I think we can address any remaining comments as part of IETF Last Call= .

NO.

We shall forward a document we are ok with. There most likely will be other= issues and comments during IETF last call.

Regards,

Christer


At 12:02 PM +0000 10/18/16, Ivo Sedlacek wrote:

>=C2=A0 Hello,
>
>=C2=A0 first of all, I am participating in 3GPP CT1 meeting this week a= nd I
> have not have time to review changes between -015 and -018 properly. > Can we shift the deadline to next week?
>
>=C2=A0 I am OK with resolution of ISSUE 1, ISSUE 3, ISSUE 8, ISSUE 13, = ISSUE
> 15, ISSUE 16, ISSUE 17, ISSUE 19.
>
>=C2=A0 On the remaining issues:
>
>>=C2=A0 >=C2=A0 ISSUE 2:
>>=C2=A0 >
>>=C2=A0 >=C2=A0 section 3 - level of technical detail of the last= paragraph of=C2=A0 >
>> section 3 does not fit with level of technical detail of the
>> remaining=C2=A0 > text of section 3.
>>
>>=C2=A0 Intermediate paragraphs were added in version 17.
>
>=C2=A0 I still believe that section 3 contains different types of infor= mation:
>=C2=A0 Type1: generic overview of the eCall requirements, existing solu= tions, ...
>=C2=A0 Type2: information about the draft
>
>=C2=A0 It would be better to split those to separate sections.

Can you elaborate on what the problem is?

>
>>=C2=A0 >=C2=A0 ISSUE 4:
>>=C2=A0 >
>>=C2=A0 >=C2=A0 section 4, "=C2=A0 =C2=A0This document regis= ters the 'application/
>>=C2=A0 >=C2=A0 =C2=A0 =C2=A0emergencyCallData.eCall.MSD+per= ' MIME Content-Type to enable the MSD
>>=C2=A0 >=C2=A0 =C2=A0 =C2=A0to be carried in SIP."
>>=C2=A0 >
>>=C2=A0 >=C2=A0 There is no MIME Content-Type registry. "MIM= E Content-Type" ->
>> "MIME type"
>>=C2=A0 >
>>=C2=A0 >=C2=A0 Same in other places of the document.
>>
>>=C2=A0 Corrected "content type" to "media type"= .
>
>=C2=A0 I can still see a few occurences of "content type" in = -018 - e.g.

Thanks, I'll do a grep.

>
>=C2=A0 ---------
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Security considerations: This ****content t= ype**** is designed to carry
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 vehicle and incident-related data during an= emergency call.=C2=A0 This
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 data contains personal information includin= g vehicle VIN,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 location, direction, etc.=C2=A0 Appropriate= precautions need to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 taken to limit unauthorized access, inappro= priate disclosure to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 third parties, and eavesdropping of this in= formation.=C2=A0 In general,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 it is acceptable for the data to be unprote= cted while briefly in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 transit within the Mobile Network Operator = (MNO); the MNO is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 trusted to not permit the data to be access= ed by third parties.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sections 7 and Section 8 of [RFC7852] conta= in more discussion.
>=C2=A0 ---------
>=C2=A0 and
>=C2=A0 ---------
>=C2=A0 =C2=A0 =C2=A0The metadata/control block is designed for use with= pan-European
>=C2=A0 =C2=A0 =C2=A0eCall and also eCall-like systems (i.e., in other r= egions), and has
>=C2=A0 =C2=A0 =C2=A0extension points.=C2=A0 Note that eCall-like system= s might define their
>=C2=A0 =C2=A0 =C2=A0own vehicle data blocks, and so might need to regis= ter a new INFO
>=C2=A0 =C2=A0 =C2=A0package to accomodate the new data ****content type= **** and the metadata/
>=C2=A0 =C2=A0 =C2=A0control object.
>=C2=A0 ---------
>=C2=A0 and
>=C2=A0 --------
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This ****content type**** carr= ies metadata and control
> information and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0requests, such as from a Publi= c Safety Answering Point (PSAP)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to an In-Vehicle System (IVS) = during an emergency call.
>=C2=A0 --------
>
>>=C2=A0 >=C2=A0 ISSUE 6:
>>=C2=A0 >
>>=C2=A0 >=C2=A0 section 6 - "An MSD or a metadata/control bl= ock is always
>> enclosed in=C2=A0 > a multipart
>>=C2=A0 >=C2=A0 =C2=A0 =C2=A0body part (even if it would otherwis= e be the only body part in the
>>=C2=A0 >=C2=A0 =C2=A0 =C2=A0SIP message)." - which multipar= t MIME type is meant?
>>=C2=A0 > multipart/mixed or multipart/alternative or ....
>>
>>=C2=A0 We do not need to specify that in this text.
>
>=C2=A0 IMO, we need to. Else, the UA can provide multipart/mixed while = PSAP
> expects multipart/alternative.

It would be hard to imagine a use case where a UA generates multipart/alter= native.=C2=A0 However, I don't mind adding text clarifying that multipa= rt/mixed is expected.

>
>>=C2=A0 >=C2=A0 ISSUE 7
>>=C2=A0 >
>>=C2=A0 >=C2=A0 section 6 - "The IVS then attaches an update= d MSD to a SIP
>>=C2=A0 >=C2=A0 =C2=A0 =C2=A0INFO request and sends it within the= dialog." - what is meant by
>>=C2=A0 > "attaching MSD to SIP INFO request"?
>>
>>=C2=A0 I think that's made abundantly clear in the multiple ear= lier
>> instances in the
>>=C2=A0 same section that say "as a MIME body part".
>
>=C2=A0 I do not really know what "attach body to SIP request"= =C2=A0 means.
> Likely, other readers will not know it either.
>
>=C2=A0 A reference to a section defining how to "attach body to SI= P
> request" would help.

It's the same section, just a little bit before.

>
>
>>=C2=A0 >=C2=A0 ISSUE 9
>>=C2=A0 >
>>=C2=A0 >=C2=A0 section 9 - what is "SIP status message"= ;?
>>
>>=C2=A0 I do not see "SIP status message" anywhere in the = document.
>
>=C2=A0 It was in -015 section 9 but it looks like it was already resolv= ed in -18.
>
>
>>=C2=A0 >=C2=A0 ISSUE 10
>>=C2=A0 >
>>=C2=A0 >=C2=A0 "
>>=C2=A0 >=C2=A0 For
>>=C2=A0 >=C2=A0 =C2=A0 =C2=A0example, if a PSAP is unable to acce= pt an eCall (e.g., due to
>>=C2=A0 >=C2=A0 =C2=A0 =C2=A0overload or too many calls from the = same location), it can reject the
>>=C2=A0 >=C2=A0 =C2=A0 =C2=A0INVITE.=C2=A0 Since a metadata/contr= ol object is also included in the SIP
>>=C2=A0 >=C2=A0 =C2=A0 =C2=A0response that rejects the call, the = IVS knows if the PSAP received
>>=C2=A0 >=C2=A0 =C2=A0 =C2=A0the MSD, and can inform the vehicle = occupants that the PSAP
>>=C2=A0 >=C2=A0 =C2=A0 =C2=A0successfully received the vehicle lo= cation and information but can't
>>=C2=A0 >=C2=A0 =C2=A0 =C2=A0talk to the occupants at that time.&= quot; - this prevents persons in
>>=C2=A0 > the car from getting emergency service of the PSAP usin= g other means
>>=C2=A0 > (e.g. using circuit switched network). Possibility for = DOS attack.
>>
>>=C2=A0 If the PSAP is overloaded (e.g., there is a very large multi= -vehicle
>>=C2=A0 incident, or another large-scale emergency incident), then t= here are likely
>>=C2=A0 to be multiple simultaneous eCall attempts.=C2=A0 The docume= nt does not
>> in any way
>>=C2=A0 dictate or mandate PSAP response.=C2=A0 PSAPs are free to re= spond as
>> they choose.
>>=C2=A0 E.g., a PSAP can accept eCalls and add them to a queue, a PS= AP can reject an
>>=C2=A0 eCall and include an ack with "received=3Dfalse", = a PSAP can reject an eCall
>>=C2=A0 and include an ack with "received=3Dtrue".=C2=A0 D= oing the latter
>> indicates that the
>>=C2=A0 PSAP has received the MSD and hence is aware of the incident= .
>
>=C2=A0 How can the UA be sure that such response was sent by PSAP and n= ot
> by an attacker, located somewhere between UA and PSAP?
>
>=C2=A0 Any SIP entity which happens to be in the path of the emergency<= br> > call INVITE request can generate a 600=C2=A0 (Busy Everywhere), 486 > (Busy Here), and 603 (Decline) response and populate it with a
> particular body.
>
>=C2=A0 It is at least a security risk and it needs to be documented.
OK, I'll add some text.

>
>>=C2=A0 >=C2=A0 ISSUE 11
>>=C2=A0 >
>>=C2=A0 >=C2=A0 "The body for an emergencyCallData.eCall.MSD= info package is a
>>=C2=A0 > multipart body." - which multipart MIME type is me= ant?
>>=C2=A0 > multipart/mixed or multipart/alternative or ....
>>
>>=C2=A0 We do not need to get into that level of detail in this text= .
>
>=C2=A0 IMO, we need to. Else, the UA can provide multipart/mixed while<= br> > PSAP expects multipart/alternative.

Same answer as above.

>
>>=C2=A0 >=C2=A0 ISSUE 14
>>=C2=A0 >
>>=C2=A0 >=C2=A0 "while others can be
>>=C2=A0 >=C2=A0 =C2=A0 =C2=A0expected to carry an occasional requ= est" - meaning of "occasional"
>>=C2=A0 > can be whatever, it depends on perspective of the user<= br> >>=C2=A0 > - once per milisecond, once per second, once per minute= , once per hour
>>=C2=A0 > or once per day?
>>
>>=C2=A0 Other text makes it clear that a request for an updated MSD = is
>> generally sent
>>=C2=A0 upon manual request of a PSAP call taker who suspects vehicl= e
>> state may have changed.
>
>=C2=A0 A statement that the request is expected to be triggered by manu= al
> action of the PSAP call taker is good, so I suggest to add it to
> this section too as expert reviewer will read it.

OK, I'll add text.

>
>>=C2=A0 >
>>=C2=A0 >=C2=A0 ISSUE 18
>>=C2=A0 >
>>=C2=A0 >=C2=A0 Accept in Figure 10 is not correct - INFO respons= e is not expected
>>=C2=A0 > to contain body.
>>
>>=C2=A0 Fixed, thanks for catching this.
>
>=C2=A0 in -18, I can still see Accept with multipart/mixed in the INFO<= br> > request in Figure 10.

I don't see it.=C2=A0 Here is Figure 10:

=C2=A0 =C2=A0 =C2=A0INFO sip:+13145551111@example.com SIP/2.0
=C2=A0 =C2=A0 =C2=A0To: <sip:+13145551111@example.com>;tag=3D9fxced76sl
=C2=A0 =C2=A0 =C2=A0From: Exemplar PSAP <urn:service:sos.ecall.auto= matic>;tag=3D8gydfe65t0
=C2=A0 =C2=A0 =C2=A0Call-ID: 3848276298220188511@atlanta.example.com
=C2=A0 =C2=A0 =C2=A0Call-Info: <cid:3456789012@atlanta.example.com>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 purpose=3Demergency= CallData.control
=C2=A0 =C2=A0 =C2=A0CSeq: 41862 INFO
=C2=A0 =C2=A0 =C2=A0Info-Package: emergencyCallData.eCall.MSD
=C2=A0 =C2=A0 =C2=A0Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER= , BYE,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SUBSCRIBE, NOTIFY, UPDATE
=C2=A0 =C2=A0 =C2=A0Content-Type: multipart/mixed; boundary=3DboundaryZZZ =C2=A0 =C2=A0 =C2=A0Content-Dispositio: Info-Package
=C2=A0 =C2=A0 =C2=A0Content-Length: ...

=C2=A0 =C2=A0 =C2=A0--boundaryZZZ
=C2=A0 =C2=A0 =C2=A0Content-Disposition: by-reference
=C2=A0 =C2=A0 =C2=A0Content-Type: application/emergencyCallData.contro= l+xml
=C2=A0 =C2=A0 =C2=A0Content-ID: <3456789012@atlanta.example.com>

=C2=A0 =C2=A0 =C2=A0<?xml version=3D"1.0" encoding=3D"UTF= -8"?>
=C2=A0 =C2=A0 =C2=A0<emergencyCallData.control
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns=3D"urn:ietf:params:xml:ns:EmergencyCallData:control"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns:xsi=3D"http://= www.w3.org/2001/XMLSchema-instance">

=C2=A0 =C2=A0 =C2=A0<request action=3D"send-data" datatype=3D&= quot;eCall.MSD"/>

=C2=A0 =C2=A0 =C2=A0</emergencyCallData.control>
=C2=A0 =C2=A0 =C2=A0 --boundaryZZZ--

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Figure 10: INFO requesting MSD




>
>=C2=A0 IMO, this is wrong as we do NOT expect a body in INFO response.<= br> > Yes, there will be a body in subsequent INFO request sent in
> opposite direction, but that's not impacted by Accept in first INF= O
> request.
>
>>=C2=A0 >
>>=C2=A0 >=C2=A0 ISSUE 20
>>=C2=A0 >
>>=C2=A0 >=C2=A0 examples contain a value of schemaLocation parame= ter which is not
>>=C2=A0 > aligned with https://www.w3.org= /TR/xmlschema-0/#schemaLocation
>>=C2=A0 > stating "The schemaLocation attribute value consis= ts of one or more
>>=C2=A0 > pairs of URI references, separated by white space. &quo= t;
>>=C2=A0 >
>>=C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xsi:sche= maLocation=3D
>>=C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"urn:ietf:params:xml:ns:EmergencyCallData:control"
>>
>>=C2=A0 Fixed.
>
>=C2=A0 I can see in -18, that you chose to remove the information about=
> schema location from the XML examples.
>=C2=A0 That's OK with me.
>
>=C2=A0 However, then you can also remove the following as it is not nee= ded any more
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns:xsi=3D"http://www= .w3.org/2001/XMLSchema-instance"

I've asked Hannes to verify the XML schema and examples as part of
IETF Last Call.

--
Randall Gellens
Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak= for myself only
-------------- Randomly selected tag: ---------------
Question Authority.=C2=A0 They usually know where the bathroom is.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 --MTV's 'Daria'

_______________________= ________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

--001a113b99de48ee61053f275d85-- From nobody Tue Oct 18 11:17:16 2016 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 B8D161294B8 for ; Tue, 18 Oct 2016 11:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 8A9Nw7tsdxAK for ; Tue, 18 Oct 2016 11:17:13 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 D4420129482 for ; Tue, 18 Oct 2016 11:17:12 -0700 (PDT) X-AuditID: c1b4fb2d-5b107980000009f7-5a-58066726c424 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id A4.17.02551.62766085; Tue, 18 Oct 2016 20:17:11 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.90]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0319.002; Tue, 18 Oct 2016 20:17:09 +0200 From: Christer Holmberg To: Az Mankin Thread-Topic: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 Thread-Index: AQHSKM9pnC2aMUPzqUuYRM5JMx1G9qCuYyYPgAAA8iD///m1AIAAJJcw Date: Tue, 18 Oct 2016 18:17:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BDB496F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BDB34E1@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BDB496FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2K7va56OluEwbT3TBZLp+5ksmhc9JTV 4vvzLkYHZo+ds+6yeyxZ8pPJY+udxywBzFFcNimpOZllqUX6dglcGb/mfmAqWPSZqaJh6jrm BsYzL5m6GDk5JARMJB78/cHcxcjFISSwnlHiSOcKdghnMaPEnus9jF2MHBxsAhYS3f+0QRpE BJQkbi2awg5iMwvUSTza2wdmCwvYSUyYMo0ZosZe4uv3l1C2m8SUt+sZQWwWAVWJjvfTWEBs XgFfifX/d7BC7HrCKPF+xmZWkASnQKDElBtXwYoYBcQkvp9awwSxTFzi1pP5UFcLSCzZc54Z whaVePn4HyuErSSx6PZnqPp8iUtN29khlglKnJz5hGUCo8gsJKNmISmbhaRsFtDLzAKaEut3 6UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0Vo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmC8Hdzy W3cH4+rXjocYBTgYlXh4FZLZIoRYE8uKK3MPMUpwMCuJ8KokAYV4UxIrq1KL8uOLSnNSiw8x SnOwKInzmq28Hy4kkJ5YkpqdmlqQWgSTZeLglGpgrCoUu/FiktzKCa5Fh+y/nfh9YVJi/9IN ckUJW+ZuCbaZf2yixDHbtdsa7qrtNHj3sTOTO2BJw5Zyk79vVqUaHvzT+MTQU9PRqP5NbvsJ tzdpB43ven907z2j2dhUac2oKagSdah8uv3/eulNtgxGIsvKO+NEq/k0/tg7ftphe2+2ue1B 5SRNJZbijERDLeai4kQAOV8IK7MCAAA= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 18:17:16 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BDB496FESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZXJlIGhhdmVu4oCZdCBiZWVuIGFueSBjb25zZW5zdXMgY2FsbHMgb24gdGhlIGlz c3VlcyBjdXJyZW50bHkgZGlzY3Vzc2VkLCBhbmQgSSBkb27igJl0IHRoaW5rIHRoZXJlIG5lZWQg dG8gYmUgYW55OiBpdOKAmXMgbW9zdGx5IGFib3V0IHNvcnRpbmcgb3V0IGFuZCBjbGFyaWZ5aW5n IGRldGFpbHMuIEkgZG9u4oCZdCB0aGluayB0aGVyZSBhcmUgYW55IG1ham9yIG9wZW4gaXNzdWVz Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBBeiBNYW5raW4gW21haWx0bzphem1h bmtpbkBnbWFpbC5jb21dDQpTZW50OiAxOCBPY3RvYmVyIDIwMTYgMjA6NTMNClRvOiBDaHJpc3Rl ciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KQ2M6IFJhbmRhbGwg R2VsbGVucyA8cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZz47IEl2byBTZWRsYWNlayA8aXZvLnNl ZGxhY2VrQGVyaWNzc29uLmNvbT47IGVjcml0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0Vjcml0 XSBJdm8ncyByZXZpZXcgb2YgZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xNQ0KDQpIaSwgZXZlcnlv bmUsDQpJJ2QgbGlrZSB0byByZW1pbmQgcGVvcGxlIHRoYXQgd2UgdXNlIHJvdWdoIGNvbnNlbnN1 cywgbm90IHBlcmZlY3QgdW5hbmltaXR5LCBhbmQgd2UgdXNlIGEgd2VsbCBkZWZpbmVkIHByb2Nl c3MsIGluY2x1ZGluZyBwcmFjdGljYWwgdGltZSBwZXJpb2RzIGZvciBvdXIgcGhhc2VzIG9mIGxh c3QgY2FsbC4gICBXZSBhbHNvIGNhcmUgYWJvdXQgInJ1bm5pbmcgY29kZSwiIGFuZCBvbmUgdGhp bmcgdGhhdCB3b3VsZCBiZSB2YWx1YWJsZSBmb3IgdGhpcyBsYXN0IGRheSBvZiB0aGUgbGFzdCBj YWxsIGlzIHRvIHNoYXJlIGluZm8gb24gc3RhdGUgb2YgaW1wbGVtZW50YXRpb24gb2YgdGhlc2Ug dHdvIHNwZWNzLiAgVGhpcyBkb2Vzbid0IG1lYW4gdGhleSBtdXN0IGJlIGZ1bGx5IGltcGxlbWVu dGVkIGFuZCBkZXBsb3llZCwgb2YgY291cnNlLCBidXQgd2hhdCB0eXBlcyBvZiBwcmFnbWF0aWMg b3IgZW1waXJpY2FsIHRlc3RzIGhhdmUgb2NjdXJyZWQgc28gZmFyPw0KSSdtIHBsYW5uaW5nIHRv IHJlcXVlc3QgSUVURiBMYXN0IENhbGwgdGhpcyBhZnRlcm5vb24gKFBhY2lmaWMgVGltZSkgYXMg cHJldmlvdXNseSBhbm5vdW5jZWQuICBUaGlzIHdpbGwgbm90IGxhdW5jaCBhbiBpbW1lZGlhdGUg SUVURiBMYXN0IENhbGwsIGJlY2F1c2UgdGhlcmUgaXMgZmlyc3QgYW4gQUQgUmV2aWV3LCBhbmQg SSB3aWxsIHdvcmsgdG8gcHJlc2VudCB0byBBbHlzc2Egd2hhdCB0aGUgcmVtYWluaW5nIGlzc3Vl cyBhcmUgaW4gdGhlIHNoZXBoZXJkJ3Mgd3JpdGV1cC4gIEknbSBvcGVuIHRvIHlvdXIgc2VuZGlu ZyBtZSB0ZXh0IGFzIGlucHV0IGZvciB0aGUgd3JpdGV1cC4NCkFsbGlzb24NCg0KDQoNCg0KT24g VHVlLCBPY3QgMTgsIDIwMTYgYXQgOToxNiBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPj4gd3JvdGU6DQpIaSwNCg0KPkkgdGhpbmsgd2UgY2FuIGFkZHJlc3MgYW55IHJlbWFpbmlu ZyBjb21tZW50cyBhcyBwYXJ0IG9mIElFVEYgTGFzdCBDYWxsLg0KDQpOTy4NCg0KV2Ugc2hhbGwg Zm9yd2FyZCBhIGRvY3VtZW50IHdlIGFyZSBvayB3aXRoLiBUaGVyZSBtb3N0IGxpa2VseSB3aWxs IGJlIG90aGVyIGlzc3VlcyBhbmQgY29tbWVudHMgZHVyaW5nIElFVEYgbGFzdCBjYWxsLg0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkF0IDEyOjAyIFBNICswMDAwIDEwLzE4LzE2LCBJdm8g U2VkbGFjZWsgd3JvdGU6DQoNCj4gIEhlbGxvLA0KPg0KPiAgZmlyc3Qgb2YgYWxsLCBJIGFtIHBh cnRpY2lwYXRpbmcgaW4gM0dQUCBDVDEgbWVldGluZyB0aGlzIHdlZWsgYW5kIEkNCj4gaGF2ZSBu b3QgaGF2ZSB0aW1lIHRvIHJldmlldyBjaGFuZ2VzIGJldHdlZW4gLTAxNSBhbmQgLTAxOCBwcm9w ZXJseS4NCj4gQ2FuIHdlIHNoaWZ0IHRoZSBkZWFkbGluZSB0byBuZXh0IHdlZWs/DQo+DQo+ICBJ IGFtIE9LIHdpdGggcmVzb2x1dGlvbiBvZiBJU1NVRSAxLCBJU1NVRSAzLCBJU1NVRSA4LCBJU1NV RSAxMywgSVNTVUUNCj4gMTUsIElTU1VFIDE2LCBJU1NVRSAxNywgSVNTVUUgMTkuDQo+DQo+ICBP biB0aGUgcmVtYWluaW5nIGlzc3VlczoNCj4NCj4+ICA+ICBJU1NVRSAyOg0KPj4gID4NCj4+ICA+ ICBzZWN0aW9uIDMgLSBsZXZlbCBvZiB0ZWNobmljYWwgZGV0YWlsIG9mIHRoZSBsYXN0IHBhcmFn cmFwaCBvZiAgPg0KPj4gc2VjdGlvbiAzIGRvZXMgbm90IGZpdCB3aXRoIGxldmVsIG9mIHRlY2hu aWNhbCBkZXRhaWwgb2YgdGhlDQo+PiByZW1haW5pbmcgID4gdGV4dCBvZiBzZWN0aW9uIDMuDQo+ Pg0KPj4gIEludGVybWVkaWF0ZSBwYXJhZ3JhcGhzIHdlcmUgYWRkZWQgaW4gdmVyc2lvbiAxNy4N Cj4NCj4gIEkgc3RpbGwgYmVsaWV2ZSB0aGF0IHNlY3Rpb24gMyBjb250YWlucyBkaWZmZXJlbnQg dHlwZXMgb2YgaW5mb3JtYXRpb246DQo+ICBUeXBlMTogZ2VuZXJpYyBvdmVydmlldyBvZiB0aGUg ZUNhbGwgcmVxdWlyZW1lbnRzLCBleGlzdGluZyBzb2x1dGlvbnMsIC4uLg0KPiAgVHlwZTI6IGlu Zm9ybWF0aW9uIGFib3V0IHRoZSBkcmFmdA0KPg0KPiAgSXQgd291bGQgYmUgYmV0dGVyIHRvIHNw bGl0IHRob3NlIHRvIHNlcGFyYXRlIHNlY3Rpb25zLg0KDQpDYW4geW91IGVsYWJvcmF0ZSBvbiB3 aGF0IHRoZSBwcm9ibGVtIGlzPw0KDQo+DQo+PiAgPiAgSVNTVUUgNDoNCj4+ICA+DQo+PiAgPiAg c2VjdGlvbiA0LCAiICAgVGhpcyBkb2N1bWVudCByZWdpc3RlcnMgdGhlICdhcHBsaWNhdGlvbi8N Cj4+ICA+ICAgICBlbWVyZ2VuY3lDYWxsRGF0YS5lQ2FsbC5NU0QrcGVyJyBNSU1FIENvbnRlbnQt VHlwZSB0byBlbmFibGUgdGhlIE1TRA0KPj4gID4gICAgIHRvIGJlIGNhcnJpZWQgaW4gU0lQLiIN Cj4+ICA+DQo+PiAgPiAgVGhlcmUgaXMgbm8gTUlNRSBDb250ZW50LVR5cGUgcmVnaXN0cnkuICJN SU1FIENvbnRlbnQtVHlwZSIgLT4NCj4+ICJNSU1FIHR5cGUiDQo+PiAgPg0KPj4gID4gIFNhbWUg aW4gb3RoZXIgcGxhY2VzIG9mIHRoZSBkb2N1bWVudC4NCj4+DQo+PiAgQ29ycmVjdGVkICJjb250 ZW50IHR5cGUiIHRvICJtZWRpYSB0eXBlIi4NCj4NCj4gIEkgY2FuIHN0aWxsIHNlZSBhIGZldyBv Y2N1cmVuY2VzIG9mICJjb250ZW50IHR5cGUiIGluIC0wMTggLSBlLmcuDQoNClRoYW5rcywgSSds bCBkbyBhIGdyZXAuDQoNCj4NCj4gIC0tLS0tLS0tLQ0KPiAgICAgICAgU2VjdXJpdHkgY29uc2lk ZXJhdGlvbnM6IFRoaXMgKioqKmNvbnRlbnQgdHlwZSoqKiogaXMgZGVzaWduZWQgdG8gY2FycnkN Cj4gICAgICAgIHZlaGljbGUgYW5kIGluY2lkZW50LXJlbGF0ZWQgZGF0YSBkdXJpbmcgYW4gZW1l cmdlbmN5IGNhbGwuICBUaGlzDQo+ICAgICAgICBkYXRhIGNvbnRhaW5zIHBlcnNvbmFsIGluZm9y bWF0aW9uIGluY2x1ZGluZyB2ZWhpY2xlIFZJTiwNCj4gICAgICAgIGxvY2F0aW9uLCBkaXJlY3Rp b24sIGV0Yy4gIEFwcHJvcHJpYXRlIHByZWNhdXRpb25zIG5lZWQgdG8gYmUNCj4gICAgICAgIHRh a2VuIHRvIGxpbWl0IHVuYXV0aG9yaXplZCBhY2Nlc3MsIGluYXBwcm9wcmlhdGUgZGlzY2xvc3Vy ZSB0bw0KPiAgICAgICAgdGhpcmQgcGFydGllcywgYW5kIGVhdmVzZHJvcHBpbmcgb2YgdGhpcyBp bmZvcm1hdGlvbi4gIEluIGdlbmVyYWwsDQo+ICAgICAgICBpdCBpcyBhY2NlcHRhYmxlIGZvciB0 aGUgZGF0YSB0byBiZSB1bnByb3RlY3RlZCB3aGlsZSBicmllZmx5IGluDQo+ICAgICAgICB0cmFu c2l0IHdpdGhpbiB0aGUgTW9iaWxlIE5ldHdvcmsgT3BlcmF0b3IgKE1OTyk7IHRoZSBNTk8gaXMN Cj4gICAgICAgIHRydXN0ZWQgdG8gbm90IHBlcm1pdCB0aGUgZGF0YSB0byBiZSBhY2Nlc3NlZCBi eSB0aGlyZCBwYXJ0aWVzLg0KPiAgICAgICAgU2VjdGlvbnMgNyBhbmQgU2VjdGlvbiA4IG9mIFtS RkM3ODUyXSBjb250YWluIG1vcmUgZGlzY3Vzc2lvbi4NCj4gIC0tLS0tLS0tLQ0KPiAgYW5kDQo+ ICAtLS0tLS0tLS0NCj4gICAgIFRoZSBtZXRhZGF0YS9jb250cm9sIGJsb2NrIGlzIGRlc2lnbmVk IGZvciB1c2Ugd2l0aCBwYW4tRXVyb3BlYW4NCj4gICAgIGVDYWxsIGFuZCBhbHNvIGVDYWxsLWxp a2Ugc3lzdGVtcyAoaS5lLiwgaW4gb3RoZXIgcmVnaW9ucyksIGFuZCBoYXMNCj4gICAgIGV4dGVu c2lvbiBwb2ludHMuICBOb3RlIHRoYXQgZUNhbGwtbGlrZSBzeXN0ZW1zIG1pZ2h0IGRlZmluZSB0 aGVpcg0KPiAgICAgb3duIHZlaGljbGUgZGF0YSBibG9ja3MsIGFuZCBzbyBtaWdodCBuZWVkIHRv IHJlZ2lzdGVyIGEgbmV3IElORk8NCj4gICAgIHBhY2thZ2UgdG8gYWNjb21vZGF0ZSB0aGUgbmV3 IGRhdGEgKioqKmNvbnRlbnQgdHlwZSoqKiogYW5kIHRoZSBtZXRhZGF0YS8NCj4gICAgIGNvbnRy b2wgb2JqZWN0Lg0KPiAgLS0tLS0tLS0tDQo+ICBhbmQNCj4gIC0tLS0tLS0tDQo+ICAgICAgICAg ICBUaGlzICoqKipjb250ZW50IHR5cGUqKioqIGNhcnJpZXMgbWV0YWRhdGEgYW5kIGNvbnRyb2wN Cj4gaW5mb3JtYXRpb24gYW5kDQo+ICAgICAgICAgICByZXF1ZXN0cywgc3VjaCBhcyBmcm9tIGEg UHVibGljIFNhZmV0eSBBbnN3ZXJpbmcgUG9pbnQgKFBTQVApDQo+ICAgICAgICAgICB0byBhbiBJ bi1WZWhpY2xlIFN5c3RlbSAoSVZTKSBkdXJpbmcgYW4gZW1lcmdlbmN5IGNhbGwuDQo+ICAtLS0t LS0tLQ0KPg0KPj4gID4gIElTU1VFIDY6DQo+PiAgPg0KPj4gID4gIHNlY3Rpb24gNiAtICJBbiBN U0Qgb3IgYSBtZXRhZGF0YS9jb250cm9sIGJsb2NrIGlzIGFsd2F5cw0KPj4gZW5jbG9zZWQgaW4g ID4gYSBtdWx0aXBhcnQNCj4+ICA+ICAgICBib2R5IHBhcnQgKGV2ZW4gaWYgaXQgd291bGQgb3Ro ZXJ3aXNlIGJlIHRoZSBvbmx5IGJvZHkgcGFydCBpbiB0aGUNCj4+ICA+ICAgICBTSVAgbWVzc2Fn ZSkuIiAtIHdoaWNoIG11bHRpcGFydCBNSU1FIHR5cGUgaXMgbWVhbnQ/DQo+PiAgPiBtdWx0aXBh cnQvbWl4ZWQgb3IgbXVsdGlwYXJ0L2FsdGVybmF0aXZlIG9yIC4uLi4NCj4+DQo+PiAgV2UgZG8g bm90IG5lZWQgdG8gc3BlY2lmeSB0aGF0IGluIHRoaXMgdGV4dC4NCj4NCj4gIElNTywgd2UgbmVl ZCB0by4gRWxzZSwgdGhlIFVBIGNhbiBwcm92aWRlIG11bHRpcGFydC9taXhlZCB3aGlsZSBQU0FQ DQo+IGV4cGVjdHMgbXVsdGlwYXJ0L2FsdGVybmF0aXZlLg0KDQpJdCB3b3VsZCBiZSBoYXJkIHRv IGltYWdpbmUgYSB1c2UgY2FzZSB3aGVyZSBhIFVBIGdlbmVyYXRlcyBtdWx0aXBhcnQvYWx0ZXJu YXRpdmUuICBIb3dldmVyLCBJIGRvbid0IG1pbmQgYWRkaW5nIHRleHQgY2xhcmlmeWluZyB0aGF0 IG11bHRpcGFydC9taXhlZCBpcyBleHBlY3RlZC4NCg0KPg0KPj4gID4gIElTU1VFIDcNCj4+ICA+ DQo+PiAgPiAgc2VjdGlvbiA2IC0gIlRoZSBJVlMgdGhlbiBhdHRhY2hlcyBhbiB1cGRhdGVkIE1T RCB0byBhIFNJUA0KPj4gID4gICAgIElORk8gcmVxdWVzdCBhbmQgc2VuZHMgaXQgd2l0aGluIHRo ZSBkaWFsb2cuIiAtIHdoYXQgaXMgbWVhbnQgYnkNCj4+ICA+ICJhdHRhY2hpbmcgTVNEIHRvIFNJ UCBJTkZPIHJlcXVlc3QiPw0KPj4NCj4+ICBJIHRoaW5rIHRoYXQncyBtYWRlIGFidW5kYW50bHkg Y2xlYXIgaW4gdGhlIG11bHRpcGxlIGVhcmxpZXINCj4+IGluc3RhbmNlcyBpbiB0aGUNCj4+ICBz YW1lIHNlY3Rpb24gdGhhdCBzYXkgImFzIGEgTUlNRSBib2R5IHBhcnQiLg0KPg0KPiAgSSBkbyBu b3QgcmVhbGx5IGtub3cgd2hhdCAiYXR0YWNoIGJvZHkgdG8gU0lQIHJlcXVlc3QiICBtZWFucy4N Cj4gTGlrZWx5LCBvdGhlciByZWFkZXJzIHdpbGwgbm90IGtub3cgaXQgZWl0aGVyLg0KPg0KPiAg QSByZWZlcmVuY2UgdG8gYSBzZWN0aW9uIGRlZmluaW5nIGhvdyB0byAiYXR0YWNoIGJvZHkgdG8g U0lQDQo+IHJlcXVlc3QiIHdvdWxkIGhlbHAuDQoNCkl0J3MgdGhlIHNhbWUgc2VjdGlvbiwganVz dCBhIGxpdHRsZSBiaXQgYmVmb3JlLg0KDQo+DQo+DQo+PiAgPiAgSVNTVUUgOQ0KPj4gID4NCj4+ ICA+ICBzZWN0aW9uIDkgLSB3aGF0IGlzICJTSVAgc3RhdHVzIG1lc3NhZ2UiPw0KPj4NCj4+ICBJ IGRvIG5vdCBzZWUgIlNJUCBzdGF0dXMgbWVzc2FnZSIgYW55d2hlcmUgaW4gdGhlIGRvY3VtZW50 Lg0KPg0KPiAgSXQgd2FzIGluIC0wMTUgc2VjdGlvbiA5IGJ1dCBpdCBsb29rcyBsaWtlIGl0IHdh cyBhbHJlYWR5IHJlc29sdmVkIGluIC0xOC4NCj4NCj4NCj4+ICA+ICBJU1NVRSAxMA0KPj4gID4N Cj4+ICA+ICAiDQo+PiAgPiAgRm9yDQo+PiAgPiAgICAgZXhhbXBsZSwgaWYgYSBQU0FQIGlzIHVu YWJsZSB0byBhY2NlcHQgYW4gZUNhbGwgKGUuZy4sIGR1ZSB0bw0KPj4gID4gICAgIG92ZXJsb2Fk IG9yIHRvbyBtYW55IGNhbGxzIGZyb20gdGhlIHNhbWUgbG9jYXRpb24pLCBpdCBjYW4gcmVqZWN0 IHRoZQ0KPj4gID4gICAgIElOVklURS4gIFNpbmNlIGEgbWV0YWRhdGEvY29udHJvbCBvYmplY3Qg aXMgYWxzbyBpbmNsdWRlZCBpbiB0aGUgU0lQDQo+PiAgPiAgICAgcmVzcG9uc2UgdGhhdCByZWpl Y3RzIHRoZSBjYWxsLCB0aGUgSVZTIGtub3dzIGlmIHRoZSBQU0FQIHJlY2VpdmVkDQo+PiAgPiAg ICAgdGhlIE1TRCwgYW5kIGNhbiBpbmZvcm0gdGhlIHZlaGljbGUgb2NjdXBhbnRzIHRoYXQgdGhl IFBTQVANCj4+ICA+ICAgICBzdWNjZXNzZnVsbHkgcmVjZWl2ZWQgdGhlIHZlaGljbGUgbG9jYXRp b24gYW5kIGluZm9ybWF0aW9uIGJ1dCBjYW4ndA0KPj4gID4gICAgIHRhbGsgdG8gdGhlIG9jY3Vw YW50cyBhdCB0aGF0IHRpbWUuIiAtIHRoaXMgcHJldmVudHMgcGVyc29ucyBpbg0KPj4gID4gdGhl IGNhciBmcm9tIGdldHRpbmcgZW1lcmdlbmN5IHNlcnZpY2Ugb2YgdGhlIFBTQVAgdXNpbmcgb3Ro ZXIgbWVhbnMNCj4+ICA+IChlLmcuIHVzaW5nIGNpcmN1aXQgc3dpdGNoZWQgbmV0d29yaykuIFBv c3NpYmlsaXR5IGZvciBET1MgYXR0YWNrLg0KPj4NCj4+ICBJZiB0aGUgUFNBUCBpcyBvdmVybG9h ZGVkIChlLmcuLCB0aGVyZSBpcyBhIHZlcnkgbGFyZ2UgbXVsdGktdmVoaWNsZQ0KPj4gIGluY2lk ZW50LCBvciBhbm90aGVyIGxhcmdlLXNjYWxlIGVtZXJnZW5jeSBpbmNpZGVudCksIHRoZW4gdGhl cmUgYXJlIGxpa2VseQ0KPj4gIHRvIGJlIG11bHRpcGxlIHNpbXVsdGFuZW91cyBlQ2FsbCBhdHRl bXB0cy4gIFRoZSBkb2N1bWVudCBkb2VzIG5vdA0KPj4gaW4gYW55IHdheQ0KPj4gIGRpY3RhdGUg b3IgbWFuZGF0ZSBQU0FQIHJlc3BvbnNlLiAgUFNBUHMgYXJlIGZyZWUgdG8gcmVzcG9uZCBhcw0K Pj4gdGhleSBjaG9vc2UuDQo+PiAgRS5nLiwgYSBQU0FQIGNhbiBhY2NlcHQgZUNhbGxzIGFuZCBh ZGQgdGhlbSB0byBhIHF1ZXVlLCBhIFBTQVAgY2FuIHJlamVjdCBhbg0KPj4gIGVDYWxsIGFuZCBp bmNsdWRlIGFuIGFjayB3aXRoICJyZWNlaXZlZD1mYWxzZSIsIGEgUFNBUCBjYW4gcmVqZWN0IGFu IGVDYWxsDQo+PiAgYW5kIGluY2x1ZGUgYW4gYWNrIHdpdGggInJlY2VpdmVkPXRydWUiLiAgRG9p bmcgdGhlIGxhdHRlcg0KPj4gaW5kaWNhdGVzIHRoYXQgdGhlDQo+PiAgUFNBUCBoYXMgcmVjZWl2 ZWQgdGhlIE1TRCBhbmQgaGVuY2UgaXMgYXdhcmUgb2YgdGhlIGluY2lkZW50Lg0KPg0KPiAgSG93 IGNhbiB0aGUgVUEgYmUgc3VyZSB0aGF0IHN1Y2ggcmVzcG9uc2Ugd2FzIHNlbnQgYnkgUFNBUCBh bmQgbm90DQo+IGJ5IGFuIGF0dGFja2VyLCBsb2NhdGVkIHNvbWV3aGVyZSBiZXR3ZWVuIFVBIGFu ZCBQU0FQPw0KPg0KPiAgQW55IFNJUCBlbnRpdHkgd2hpY2ggaGFwcGVucyB0byBiZSBpbiB0aGUg cGF0aCBvZiB0aGUgZW1lcmdlbmN5DQo+IGNhbGwgSU5WSVRFIHJlcXVlc3QgY2FuIGdlbmVyYXRl IGEgNjAwICAoQnVzeSBFdmVyeXdoZXJlKSwgNDg2DQo+IChCdXN5IEhlcmUpLCBhbmQgNjAzIChE ZWNsaW5lKSByZXNwb25zZSBhbmQgcG9wdWxhdGUgaXQgd2l0aCBhDQo+IHBhcnRpY3VsYXIgYm9k eS4NCj4NCj4gIEl0IGlzIGF0IGxlYXN0IGEgc2VjdXJpdHkgcmlzayBhbmQgaXQgbmVlZHMgdG8g YmUgZG9jdW1lbnRlZC4NCg0KT0ssIEknbGwgYWRkIHNvbWUgdGV4dC4NCg0KPg0KPj4gID4gIElT U1VFIDExDQo+PiAgPg0KPj4gID4gICJUaGUgYm9keSBmb3IgYW4gZW1lcmdlbmN5Q2FsbERhdGEu ZUNhbGwuTVNEIGluZm8gcGFja2FnZSBpcyBhDQo+PiAgPiBtdWx0aXBhcnQgYm9keS4iIC0gd2hp Y2ggbXVsdGlwYXJ0IE1JTUUgdHlwZSBpcyBtZWFudD8NCj4+ICA+IG11bHRpcGFydC9taXhlZCBv ciBtdWx0aXBhcnQvYWx0ZXJuYXRpdmUgb3IgLi4uLg0KPj4NCj4+ICBXZSBkbyBub3QgbmVlZCB0 byBnZXQgaW50byB0aGF0IGxldmVsIG9mIGRldGFpbCBpbiB0aGlzIHRleHQuDQo+DQo+ICBJTU8s IHdlIG5lZWQgdG8uIEVsc2UsIHRoZSBVQSBjYW4gcHJvdmlkZSBtdWx0aXBhcnQvbWl4ZWQgd2hp bGUNCj4gUFNBUCBleHBlY3RzIG11bHRpcGFydC9hbHRlcm5hdGl2ZS4NCg0KU2FtZSBhbnN3ZXIg YXMgYWJvdmUuDQoNCj4NCj4+ICA+ICBJU1NVRSAxNA0KPj4gID4NCj4+ICA+ICAid2hpbGUgb3Ro ZXJzIGNhbiBiZQ0KPj4gID4gICAgIGV4cGVjdGVkIHRvIGNhcnJ5IGFuIG9jY2FzaW9uYWwgcmVx dWVzdCIgLSBtZWFuaW5nIG9mICJvY2Nhc2lvbmFsIg0KPj4gID4gY2FuIGJlIHdoYXRldmVyLCBp dCBkZXBlbmRzIG9uIHBlcnNwZWN0aXZlIG9mIHRoZSB1c2VyDQo+PiAgPiAtIG9uY2UgcGVyIG1p bGlzZWNvbmQsIG9uY2UgcGVyIHNlY29uZCwgb25jZSBwZXIgbWludXRlLCBvbmNlIHBlciBob3Vy DQo+PiAgPiBvciBvbmNlIHBlciBkYXk/DQo+Pg0KPj4gIE90aGVyIHRleHQgbWFrZXMgaXQgY2xl YXIgdGhhdCBhIHJlcXVlc3QgZm9yIGFuIHVwZGF0ZWQgTVNEIGlzDQo+PiBnZW5lcmFsbHkgc2Vu dA0KPj4gIHVwb24gbWFudWFsIHJlcXVlc3Qgb2YgYSBQU0FQIGNhbGwgdGFrZXIgd2hvIHN1c3Bl Y3RzIHZlaGljbGUNCj4+IHN0YXRlIG1heSBoYXZlIGNoYW5nZWQuDQo+DQo+ICBBIHN0YXRlbWVu dCB0aGF0IHRoZSByZXF1ZXN0IGlzIGV4cGVjdGVkIHRvIGJlIHRyaWdnZXJlZCBieSBtYW51YWwN Cj4gYWN0aW9uIG9mIHRoZSBQU0FQIGNhbGwgdGFrZXIgaXMgZ29vZCwgc28gSSBzdWdnZXN0IHRv IGFkZCBpdCB0bw0KPiB0aGlzIHNlY3Rpb24gdG9vIGFzIGV4cGVydCByZXZpZXdlciB3aWxsIHJl YWQgaXQuDQoNCk9LLCBJJ2xsIGFkZCB0ZXh0Lg0KDQo+DQo+PiAgPg0KPj4gID4gIElTU1VFIDE4 DQo+PiAgPg0KPj4gID4gIEFjY2VwdCBpbiBGaWd1cmUgMTAgaXMgbm90IGNvcnJlY3QgLSBJTkZP IHJlc3BvbnNlIGlzIG5vdCBleHBlY3RlZA0KPj4gID4gdG8gY29udGFpbiBib2R5Lg0KPj4NCj4+ ICBGaXhlZCwgdGhhbmtzIGZvciBjYXRjaGluZyB0aGlzLg0KPg0KPiAgaW4gLTE4LCBJIGNhbiBz dGlsbCBzZWUgQWNjZXB0IHdpdGggbXVsdGlwYXJ0L21peGVkIGluIHRoZSBJTkZPDQo+IHJlcXVl c3QgaW4gRmlndXJlIDEwLg0KDQpJIGRvbid0IHNlZSBpdC4gIEhlcmUgaXMgRmlndXJlIDEwOg0K DQogICAgIElORk8gc2lwOisxMzE0NTU1MTExMUBleGFtcGxlLmNvbTxtYWlsdG86c2lwJTNBJTJC MTMxNDU1NTExMTFAZXhhbXBsZS5jb20+IFNJUC8yLjANCiAgICAgVG86IDxzaXA6KzEzMTQ1NTUx MTExQGV4YW1wbGUuY29tPG1haWx0bzpzaXAlM0ElMkIxMzE0NTU1MTExMUBleGFtcGxlLmNvbT4+ O3RhZz05ZnhjZWQ3NnNsDQogICAgIEZyb206IEV4ZW1wbGFyIFBTQVAgPHVybjpzZXJ2aWNlOnNv cy5lY2FsbC5hdXRvbWF0aWM+O3RhZz04Z3lkZmU2NXQwDQogICAgIENhbGwtSUQ6IDM4NDgyNzYy OTgyMjAxODg1MTFAYXRsYW50YS5leGFtcGxlLmNvbTxtYWlsdG86Mzg0ODI3NjI5ODIyMDE4ODUx MUBhdGxhbnRhLmV4YW1wbGUuY29tPg0KICAgICBDYWxsLUluZm86IDxjaWQ6MzQ1Njc4OTAxMkBh dGxhbnRhLmV4YW1wbGUuY29tPG1haWx0bzpjaWQlM0EzNDU2Nzg5MDEyQGF0bGFudGEuZXhhbXBs ZS5jb20+PjsNCiAgICAgICAgICAgICAgICBwdXJwb3NlPWVtZXJnZW5jeUNhbGxEYXRhLmNvbnRy b2wNCiAgICAgQ1NlcTogNDE4NjIgSU5GTw0KICAgICBJbmZvLVBhY2thZ2U6IGVtZXJnZW5jeUNh bGxEYXRhLmVDYWxsLk1TRA0KICAgICBBbGxvdzogSU5WSVRFLCBBQ0ssIFBSQUNLLCBJTkZPLCBP UFRJT05TLCBDQU5DRUwsIFJFRkVSLCBCWUUsDQogICAgICAgICAgICBTVUJTQ1JJQkUsIE5PVElG WSwgVVBEQVRFDQogICAgIENvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOyBib3VuZGFyeT1i b3VuZGFyeVpaWg0KICAgICBDb250ZW50LURpc3Bvc2l0aW86IEluZm8tUGFja2FnZQ0KICAgICBD b250ZW50LUxlbmd0aDogLi4uDQoNCiAgICAgLS1ib3VuZGFyeVpaWg0KICAgICBDb250ZW50LURp c3Bvc2l0aW9uOiBieS1yZWZlcmVuY2UNCiAgICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9l bWVyZ2VuY3lDYWxsRGF0YS5jb250cm9sK3htbA0KICAgICBDb250ZW50LUlEOiA8MzQ1Njc4OTAx MkBhdGxhbnRhLmV4YW1wbGUuY29tPG1haWx0bzozNDU2Nzg5MDEyQGF0bGFudGEuZXhhbXBsZS5j b20+Pg0KDQogICAgIDw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+DQogICAg IDxlbWVyZ2VuY3lDYWxsRGF0YS5jb250cm9sDQogICAgICAgICB4bWxucz0idXJuOmlldGY6cGFy YW1zOnhtbDpuczpFbWVyZ2VuY3lDYWxsRGF0YTpjb250cm9sIg0KICAgICAgICAgeG1sbnM6eHNp PSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSI+DQoNCiAgICAgPHJl cXVlc3QgYWN0aW9uPSJzZW5kLWRhdGEiIGRhdGF0eXBlPSJlQ2FsbC5NU0QiLz4NCg0KICAgICA8 L2VtZXJnZW5jeUNhbGxEYXRhLmNvbnRyb2w+DQogICAgICAtLWJvdW5kYXJ5WlpaLS0NCg0KICAg ICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTA6IElORk8gcmVxdWVzdGluZyBNU0QNCg0KDQoN Cg0KPg0KPiAgSU1PLCB0aGlzIGlzIHdyb25nIGFzIHdlIGRvIE5PVCBleHBlY3QgYSBib2R5IGlu IElORk8gcmVzcG9uc2UuDQo+IFllcywgdGhlcmUgd2lsbCBiZSBhIGJvZHkgaW4gc3Vic2VxdWVu dCBJTkZPIHJlcXVlc3Qgc2VudCBpbg0KPiBvcHBvc2l0ZSBkaXJlY3Rpb24sIGJ1dCB0aGF0J3Mg bm90IGltcGFjdGVkIGJ5IEFjY2VwdCBpbiBmaXJzdCBJTkZPDQo+IHJlcXVlc3QuDQo+DQo+PiAg Pg0KPj4gID4gIElTU1VFIDIwDQo+PiAgPg0KPj4gID4gIGV4YW1wbGVzIGNvbnRhaW4gYSB2YWx1 ZSBvZiBzY2hlbWFMb2NhdGlvbiBwYXJhbWV0ZXIgd2hpY2ggaXMgbm90DQo+PiAgPiBhbGlnbmVk IHdpdGggaHR0cHM6Ly93d3cudzMub3JnL1RSL3htbHNjaGVtYS0wLyNzY2hlbWFMb2NhdGlvbg0K Pj4gID4gc3RhdGluZyAiVGhlIHNjaGVtYUxvY2F0aW9uIGF0dHJpYnV0ZSB2YWx1ZSBjb25zaXN0 cyBvZiBvbmUgb3IgbW9yZQ0KPj4gID4gcGFpcnMgb2YgVVJJIHJlZmVyZW5jZXMsIHNlcGFyYXRl ZCBieSB3aGl0ZSBzcGFjZS4gIg0KPj4gID4NCj4+ICA+ICAgICAgICAgICAgIHhzaTpzY2hlbWFM b2NhdGlvbj0NCj4+ICA+ICAgICAgICAgICAgICAgICAidXJuOmlldGY6cGFyYW1zOnhtbDpuczpF bWVyZ2VuY3lDYWxsRGF0YTpjb250cm9sIg0KPj4NCj4+ICBGaXhlZC4NCj4NCj4gIEkgY2FuIHNl ZSBpbiAtMTgsIHRoYXQgeW91IGNob3NlIHRvIHJlbW92ZSB0aGUgaW5mb3JtYXRpb24gYWJvdXQN Cj4gc2NoZW1hIGxvY2F0aW9uIGZyb20gdGhlIFhNTCBleGFtcGxlcy4NCj4gIFRoYXQncyBPSyB3 aXRoIG1lLg0KPg0KPiAgSG93ZXZlciwgdGhlbiB5b3UgY2FuIGFsc28gcmVtb3ZlIHRoZSBmb2xs b3dpbmcgYXMgaXQgaXMgbm90IG5lZWRlZCBhbnkgbW9yZQ0KPg0KPiAgICAgICB4bWxuczp4c2k9 Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIg0KDQpJJ3ZlIGFza2Vk IEhhbm5lcyB0byB2ZXJpZnkgdGhlIFhNTCBzY2hlbWEgYW5kIGV4YW1wbGVzIGFzIHBhcnQgb2YN CklFVEYgTGFzdCBDYWxsLg0KDQotLQ0KUmFuZGFsbCBHZWxsZW5zDQpPcGluaW9ucyBhcmUgcGVy c29uYWw7ICAgIGZhY3RzIGFyZSBzdXNwZWN0OyAgICBJIHNwZWFrIGZvciBteXNlbGYgb25seQ0K LS0tLS0tLS0tLS0tLS0gUmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAtLS0tLS0tLS0tLS0tLS0NClF1 ZXN0aW9uIEF1dGhvcml0eS4gIFRoZXkgdXN1YWxseSBrbm93IHdoZXJlIHRoZSBiYXRocm9vbSBp cy4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLU1UVidz ICdEYXJpYScNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpFY3JpdCBtYWlsaW5nIGxpc3QNCkVjcml0QGlldGYub3JnPG1haWx0bzpFY3JpdEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0K --_000_7594FB04B1934943A5C02806D1A2204B4BDB496FESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5UaGVyZSBoYXZlbuKAmXQgYmVlbiBhbnkgY29uc2Vuc3VzIGNhbGxz IG9uIHRoZSBpc3N1ZXMgY3VycmVudGx5IGRpc2N1c3NlZCwgYW5kIEkgZG9u4oCZdCB0aGluayB0 aGVyZSBuZWVkIHRvIGJlIGFueTogaXTigJlzIG1vc3RseSBhYm91dA0KIHNvcnRpbmcgb3V0IGFu ZCBjbGFyaWZ5aW5nIGRldGFpbHMuIEkgZG9u4oCZdCB0aGluayB0aGVyZSBhcmUgYW55IG1ham9y IG9wZW4gaXNzdWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxF bmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQXogTWFua2luIFttYWlsdG86YXptYW5r aW5AZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDE4IE9jdG9iZXIgMjAxNiAyMDo1Mzxi cj4NCjxiPlRvOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFJhbmRhbGwgR2VsbGVucyAmbHQ7cmcmIzQz O2lldGZAcmFuZHkucGVuc2l2ZS5vcmcmZ3Q7OyBJdm8gU2VkbGFjZWsgJmx0O2l2by5zZWRsYWNl a0Blcmljc3Nvbi5jb20mZ3Q7OyBlY3JpdEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW0Vjcml0XSBJdm8ncyByZXZpZXcgb2YgZHJhZnQtaWV0Zi1lY3JpdC1lY2FsbC0xNTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGksIGV2ZXJ5b25lLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PkknZCBsaWtlIHRvIHJlbWluZCBwZW9wbGUgdGhhdCB3ZSB1c2Ugcm91Z2ggY29uc2Vuc3VzLCBu b3QgcGVyZmVjdCB1bmFuaW1pdHksIGFuZCB3ZSB1c2UgYSB3ZWxsIGRlZmluZWQgcHJvY2Vzcywg aW5jbHVkaW5nIHByYWN0aWNhbCB0aW1lIHBlcmlvZHMgZm9yIG91ciBwaGFzZXMgb2YgbGFzdCBj YWxsLiZuYnNwOyZuYnNwOyBXZSBhbHNvIGNhcmUgYWJvdXQgJnF1b3Q7cnVubmluZyBjb2RlLCZx dW90Ow0KIGFuZCBvbmUgdGhpbmcgdGhhdCB3b3VsZCBiZSB2YWx1YWJsZSBmb3IgdGhpcyBsYXN0 IGRheSBvZiB0aGUgbGFzdCBjYWxsIGlzIHRvIHNoYXJlIGluZm8gb24gc3RhdGUgb2YgaW1wbGVt ZW50YXRpb24gb2YgdGhlc2UgdHdvIHNwZWNzLiZuYnNwOyBUaGlzIGRvZXNuJ3QgbWVhbiB0aGV5 IG11c3QgYmUgZnVsbHkgaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkLCBvZiBjb3Vyc2UsIGJ1dCB3 aGF0IHR5cGVzIG9mIHByYWdtYXRpYyBvciBlbXBpcmljYWwgdGVzdHMNCiBoYXZlIG9jY3VycmVk IHNvIGZhcj8gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSdtIHBsYW5uaW5nIHRvIHJlcXVlc3QgSUVURiBM YXN0IENhbGwgdGhpcyBhZnRlcm5vb24gKFBhY2lmaWMgVGltZSkgYXMgcHJldmlvdXNseSBhbm5v dW5jZWQuJm5ic3A7IFRoaXMgd2lsbCBub3QgbGF1bmNoIGFuIGltbWVkaWF0ZSBJRVRGIExhc3Qg Q2FsbCwgYmVjYXVzZSB0aGVyZSBpcyBmaXJzdCBhbiBBRCBSZXZpZXcsIGFuZCBJIHdpbGwgd29y ayB0byBwcmVzZW50DQogdG8gQWx5c3NhIHdoYXQgdGhlIHJlbWFpbmluZyBpc3N1ZXMgYXJlIGlu IHRoZSBzaGVwaGVyZCdzIHdyaXRldXAuJm5ic3A7IEknbSBvcGVuIHRvIHlvdXIgc2VuZGluZyBt ZSB0ZXh0IGFzIGlucHV0IGZvciB0aGUgd3JpdGV1cC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbGlzb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE9jdCAxOCwgMjAxNiBhdCA5OjE2IEFN LCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpLDxicj4NCjxicj4NCiZndDtJIHRoaW5rIHdlIGNhbiBhZGRyZXNzIGFu eSByZW1haW5pbmcgY29tbWVudHMgYXMgcGFydCBvZiBJRVRGIExhc3QgQ2FsbC48YnI+DQo8YnI+ DQpOTy48YnI+DQo8YnI+DQpXZSBzaGFsbCBmb3J3YXJkIGEgZG9jdW1lbnQgd2UgYXJlIG9rIHdp dGguIFRoZXJlIG1vc3QgbGlrZWx5IHdpbGwgYmUgb3RoZXIgaXNzdWVzIGFuZCBjb21tZW50cyBk dXJpbmcgSUVURiBsYXN0IGNhbGwuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpDaHJp c3RlcjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCkF0IDEyOjAyIFBNICYjNDM7 MDAwMCAxMC8xOC8xNiwgSXZvIFNlZGxhY2VrIHdyb3RlOjxicj4NCjxicj4NCiZndDsmbmJzcDsg SGVsbG8sPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgZmlyc3Qgb2YgYWxsLCBJIGFtIHBhcnRp Y2lwYXRpbmcgaW4gM0dQUCBDVDEgbWVldGluZyB0aGlzIHdlZWsgYW5kIEk8YnI+DQomZ3Q7IGhh dmUgbm90IGhhdmUgdGltZSB0byByZXZpZXcgY2hhbmdlcyBiZXR3ZWVuIC0wMTUgYW5kIC0wMTgg cHJvcGVybHkuPGJyPg0KJmd0OyBDYW4gd2Ugc2hpZnQgdGhlIGRlYWRsaW5lIHRvIG5leHQgd2Vl az88YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyBJIGFtIE9LIHdpdGggcmVzb2x1dGlvbiBvZiBJ U1NVRSAxLCBJU1NVRSAzLCBJU1NVRSA4LCBJU1NVRSAxMywgSVNTVUU8YnI+DQomZ3Q7IDE1LCBJ U1NVRSAxNiwgSVNTVUUgMTcsIElTU1VFIDE5Ljxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7IE9u IHRoZSByZW1haW5pbmcgaXNzdWVzOjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7 Jm5ic3A7IElTU1VFIDI6PGJyPg0KJmd0OyZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jm5i c3A7ICZndDsmbmJzcDsgc2VjdGlvbiAzIC0gbGV2ZWwgb2YgdGVjaG5pY2FsIGRldGFpbCBvZiB0 aGUgbGFzdCBwYXJhZ3JhcGggb2YmbmJzcDsgJmd0Ozxicj4NCiZndDsmZ3Q7IHNlY3Rpb24gMyBk b2VzIG5vdCBmaXQgd2l0aCBsZXZlbCBvZiB0ZWNobmljYWwgZGV0YWlsIG9mIHRoZTxicj4NCiZn dDsmZ3Q7IHJlbWFpbmluZyZuYnNwOyAmZ3Q7IHRleHQgb2Ygc2VjdGlvbiAzLjxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgSW50ZXJtZWRpYXRlIHBhcmFncmFwaHMgd2VyZSBhZGRl ZCBpbiB2ZXJzaW9uIDE3Ljxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7IEkgc3RpbGwgYmVsaWV2 ZSB0aGF0IHNlY3Rpb24gMyBjb250YWlucyBkaWZmZXJlbnQgdHlwZXMgb2YgaW5mb3JtYXRpb246 PGJyPg0KJmd0OyZuYnNwOyBUeXBlMTogZ2VuZXJpYyBvdmVydmlldyBvZiB0aGUgZUNhbGwgcmVx dWlyZW1lbnRzLCBleGlzdGluZyBzb2x1dGlvbnMsIC4uLjxicj4NCiZndDsmbmJzcDsgVHlwZTI6 IGluZm9ybWF0aW9uIGFib3V0IHRoZSBkcmFmdDxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7IEl0 IHdvdWxkIGJlIGJldHRlciB0byBzcGxpdCB0aG9zZSB0byBzZXBhcmF0ZSBzZWN0aW9ucy48YnI+ DQo8YnI+DQpDYW4geW91IGVsYWJvcmF0ZSBvbiB3aGF0IHRoZSBwcm9ibGVtIGlzPzxicj4NCjxi cj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7Jm5ic3A7IElTU1VFIDQ6PGJyPg0KJmd0 OyZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZndDsmbmJzcDsgc2VjdGlvbiA0 LCAmcXVvdDsmbmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCByZWdpc3RlcnMgdGhlICdhcHBsaWNh dGlvbi88YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtlbWVyZ2Vu Y3lDYWxsRGF0YS5lQ2FsbC5NU0QmIzQzO3BlcicgTUlNRSBDb250ZW50LVR5cGUgdG8gZW5hYmxl IHRoZSBNU0Q8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt0byBi ZSBjYXJyaWVkIGluIFNJUC4mcXVvdDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0 OyZndDsmbmJzcDsgJmd0OyZuYnNwOyBUaGVyZSBpcyBubyBNSU1FIENvbnRlbnQtVHlwZSByZWdp c3RyeS4gJnF1b3Q7TUlNRSBDb250ZW50LVR5cGUmcXVvdDsgLSZndDs8YnI+DQomZ3Q7Jmd0OyAm cXVvdDtNSU1FIHR5cGUmcXVvdDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZn dDsmbmJzcDsgJmd0OyZuYnNwOyBTYW1lIGluIG90aGVyIHBsYWNlcyBvZiB0aGUgZG9jdW1lbnQu PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyBDb3JyZWN0ZWQgJnF1b3Q7Y29udGVu dCB0eXBlJnF1b3Q7IHRvICZxdW90O21lZGlhIHR5cGUmcXVvdDsuPGJyPg0KJmd0Ozxicj4NCiZn dDsmbmJzcDsgSSBjYW4gc3RpbGwgc2VlIGEgZmV3IG9jY3VyZW5jZXMgb2YgJnF1b3Q7Y29udGVu dCB0eXBlJnF1b3Q7IGluIC0wMTggLSBlLmcuPGJyPg0KPGJyPg0KVGhhbmtzLCBJJ2xsIGRvIGEg Z3JlcC48YnI+DQo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAtLS0tLS0tLS08YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zOiBUaGlz ICoqKipjb250ZW50IHR5cGUqKioqIGlzIGRlc2lnbmVkIHRvIGNhcnJ5PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB2ZWhpY2xlIGFuZCBpbmNpZGVudC1yZWxhdGVkIGRhdGEg ZHVyaW5nIGFuIGVtZXJnZW5jeSBjYWxsLiZuYnNwOyBUaGlzPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBkYXRhIGNvbnRhaW5zIHBlcnNvbmFsIGluZm9ybWF0aW9uIGluY2x1 ZGluZyB2ZWhpY2xlIFZJTiw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxv Y2F0aW9uLCBkaXJlY3Rpb24sIGV0Yy4mbmJzcDsgQXBwcm9wcmlhdGUgcHJlY2F1dGlvbnMgbmVl ZCB0byBiZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGFrZW4gdG8gbGlt aXQgdW5hdXRob3JpemVkIGFjY2VzcywgaW5hcHByb3ByaWF0ZSBkaXNjbG9zdXJlIHRvPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGlyZCBwYXJ0aWVzLCBhbmQgZWF2ZXNk cm9wcGluZyBvZiB0aGlzIGluZm9ybWF0aW9uLiZuYnNwOyBJbiBnZW5lcmFsLDxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaXQgaXMgYWNjZXB0YWJsZSBmb3IgdGhlIGRhdGEg dG8gYmUgdW5wcm90ZWN0ZWQgd2hpbGUgYnJpZWZseSBpbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgdHJhbnNpdCB3aXRoaW4gdGhlIE1vYmlsZSBOZXR3b3JrIE9wZXJhdG9y IChNTk8pOyB0aGUgTU5PIGlzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0 cnVzdGVkIHRvIG5vdCBwZXJtaXQgdGhlIGRhdGEgdG8gYmUgYWNjZXNzZWQgYnkgdGhpcmQgcGFy dGllcy48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFNlY3Rpb25zIDcgYW5k IFNlY3Rpb24gOCBvZiBbUkZDNzg1Ml0gY29udGFpbiBtb3JlIGRpc2N1c3Npb24uPGJyPg0KJmd0 OyZuYnNwOyAtLS0tLS0tLS08YnI+DQomZ3Q7Jm5ic3A7IGFuZDxicj4NCiZndDsmbmJzcDsgLS0t LS0tLS0tPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIG1ldGFkYXRhL2NvbnRyb2wg YmxvY2sgaXMgZGVzaWduZWQgZm9yIHVzZSB3aXRoIHBhbi1FdXJvcGVhbjxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwO2VDYWxsIGFuZCBhbHNvIGVDYWxsLWxpa2Ugc3lzdGVtcyAoaS5lLiwg aW4gb3RoZXIgcmVnaW9ucyksIGFuZCBoYXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtl eHRlbnNpb24gcG9pbnRzLiZuYnNwOyBOb3RlIHRoYXQgZUNhbGwtbGlrZSBzeXN0ZW1zIG1pZ2h0 IGRlZmluZSB0aGVpcjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO293biB2ZWhpY2xlIGRh dGEgYmxvY2tzLCBhbmQgc28gbWlnaHQgbmVlZCB0byByZWdpc3RlciBhIG5ldyBJTkZPPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7cGFja2FnZSB0byBhY2NvbW9kYXRlIHRoZSBuZXcgZGF0 YSAqKioqY29udGVudCB0eXBlKioqKiBhbmQgdGhlIG1ldGFkYXRhLzxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwO2NvbnRyb2wgb2JqZWN0Ljxicj4NCiZndDsmbmJzcDsgLS0tLS0tLS0tPGJy Pg0KJmd0OyZuYnNwOyBhbmQ8YnI+DQomZ3Q7Jm5ic3A7IC0tLS0tLS0tPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhpcyAqKioqY29udGVudCB0eXBl KioqKiBjYXJyaWVzIG1ldGFkYXRhIGFuZCBjb250cm9sPGJyPg0KJmd0OyBpbmZvcm1hdGlvbiBh bmQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyZXF1 ZXN0cywgc3VjaCBhcyBmcm9tIGEgUHVibGljIFNhZmV0eSBBbnN3ZXJpbmcgUG9pbnQgKFBTQVAp PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dG8gYW4g SW4tVmVoaWNsZSBTeXN0ZW0gKElWUykgZHVyaW5nIGFuIGVtZXJnZW5jeSBjYWxsLjxicj4NCiZn dDsmbmJzcDsgLS0tLS0tLS08YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJmd0OyZuYnNw OyBJU1NVRSA2Ojxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAm Z3Q7Jm5ic3A7IHNlY3Rpb24gNiAtICZxdW90O0FuIE1TRCBvciBhIG1ldGFkYXRhL2NvbnRyb2wg YmxvY2sgaXMgYWx3YXlzPGJyPg0KJmd0OyZndDsgZW5jbG9zZWQgaW4mbmJzcDsgJmd0OyBhIG11 bHRpcGFydDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2JvZHkg cGFydCAoZXZlbiBpZiBpdCB3b3VsZCBvdGhlcndpc2UgYmUgdGhlIG9ubHkgYm9keSBwYXJ0IGlu IHRoZTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO1NJUCBtZXNz YWdlKS4mcXVvdDsgLSB3aGljaCBtdWx0aXBhcnQgTUlNRSB0eXBlIGlzIG1lYW50Pzxicj4NCiZn dDsmZ3Q7Jm5ic3A7ICZndDsgbXVsdGlwYXJ0L21peGVkIG9yIG11bHRpcGFydC9hbHRlcm5hdGl2 ZSBvciAuLi4uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyBXZSBkbyBub3QgbmVl ZCB0byBzcGVjaWZ5IHRoYXQgaW4gdGhpcyB0ZXh0Ljxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7 IElNTywgd2UgbmVlZCB0by4gRWxzZSwgdGhlIFVBIGNhbiBwcm92aWRlIG11bHRpcGFydC9taXhl ZCB3aGlsZSBQU0FQPGJyPg0KJmd0OyBleHBlY3RzIG11bHRpcGFydC9hbHRlcm5hdGl2ZS48YnI+ DQo8YnI+DQpJdCB3b3VsZCBiZSBoYXJkIHRvIGltYWdpbmUgYSB1c2UgY2FzZSB3aGVyZSBhIFVB IGdlbmVyYXRlcyBtdWx0aXBhcnQvYWx0ZXJuYXRpdmUuJm5ic3A7IEhvd2V2ZXIsIEkgZG9uJ3Qg bWluZCBhZGRpbmcgdGV4dCBjbGFyaWZ5aW5nIHRoYXQgbXVsdGlwYXJ0L21peGVkIGlzIGV4cGVj dGVkLjxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7Jm5ic3A7IElTU1VF IDc8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJmd0OyZuYnNw OyBzZWN0aW9uIDYgLSAmcXVvdDtUaGUgSVZTIHRoZW4gYXR0YWNoZXMgYW4gdXBkYXRlZCBNU0Qg dG8gYSBTSVA8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtJTkZP IHJlcXVlc3QgYW5kIHNlbmRzIGl0IHdpdGhpbiB0aGUgZGlhbG9nLiZxdW90OyAtIHdoYXQgaXMg bWVhbnQgYnk8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7ICZxdW90O2F0dGFjaGluZyBNU0QgdG8g U0lQIElORk8gcmVxdWVzdCZxdW90Oz88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7 IEkgdGhpbmsgdGhhdCdzIG1hZGUgYWJ1bmRhbnRseSBjbGVhciBpbiB0aGUgbXVsdGlwbGUgZWFy bGllcjxicj4NCiZndDsmZ3Q7IGluc3RhbmNlcyBpbiB0aGU8YnI+DQomZ3Q7Jmd0OyZuYnNwOyBz YW1lIHNlY3Rpb24gdGhhdCBzYXkgJnF1b3Q7YXMgYSBNSU1FIGJvZHkgcGFydCZxdW90Oy48YnI+ DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyBJIGRvIG5vdCByZWFsbHkga25vdyB3aGF0ICZxdW90O2F0 dGFjaCBib2R5IHRvIFNJUCByZXF1ZXN0JnF1b3Q7Jm5ic3A7IG1lYW5zLjxicj4NCiZndDsgTGlr ZWx5LCBvdGhlciByZWFkZXJzIHdpbGwgbm90IGtub3cgaXQgZWl0aGVyLjxicj4NCiZndDs8YnI+ DQomZ3Q7Jm5ic3A7IEEgcmVmZXJlbmNlIHRvIGEgc2VjdGlvbiBkZWZpbmluZyBob3cgdG8gJnF1 b3Q7YXR0YWNoIGJvZHkgdG8gU0lQPGJyPg0KJmd0OyByZXF1ZXN0JnF1b3Q7IHdvdWxkIGhlbHAu PGJyPg0KPGJyPg0KSXQncyB0aGUgc2FtZSBzZWN0aW9uLCBqdXN0IGEgbGl0dGxlIGJpdCBiZWZv cmUuPGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7Jm5i c3A7IElTU1VFIDk8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsg Jmd0OyZuYnNwOyBzZWN0aW9uIDkgLSB3aGF0IGlzICZxdW90O1NJUCBzdGF0dXMgbWVzc2FnZSZx dW90Oz88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7IEkgZG8gbm90IHNlZSAmcXVv dDtTSVAgc3RhdHVzIG1lc3NhZ2UmcXVvdDsgYW55d2hlcmUgaW4gdGhlIGRvY3VtZW50Ljxicj4N CiZndDs8YnI+DQomZ3Q7Jm5ic3A7IEl0IHdhcyBpbiAtMDE1IHNlY3Rpb24gOSBidXQgaXQgbG9v a3MgbGlrZSBpdCB3YXMgYWxyZWFkeSByZXNvbHZlZCBpbiAtMTguPGJyPg0KJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7Jm5ic3A7IElTU1VFIDEwPGJyPg0KJmd0OyZndDsm bmJzcDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZndDsmbmJzcDsgJnF1b3Q7PGJyPg0KJmd0 OyZndDsmbmJzcDsgJmd0OyZuYnNwOyBGb3I8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDtleGFtcGxlLCBpZiBhIFBTQVAgaXMgdW5hYmxlIHRvIGFjY2VwdCBhbiBl Q2FsbCAoZS5nLiwgZHVlIHRvPGJyPg0KJmd0OyZndDsmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7b3ZlcmxvYWQgb3IgdG9vIG1hbnkgY2FsbHMgZnJvbSB0aGUgc2FtZSBsb2NhdGlvbiks IGl0IGNhbiByZWplY3QgdGhlPGJyPg0KJmd0OyZndDsmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7SU5WSVRFLiZuYnNwOyBTaW5jZSBhIG1ldGFkYXRhL2NvbnRyb2wgb2JqZWN0IGlzIGFs c28gaW5jbHVkZWQgaW4gdGhlIFNJUDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZndDsmbmJzcDsgJm5i c3A7ICZuYnNwO3Jlc3BvbnNlIHRoYXQgcmVqZWN0cyB0aGUgY2FsbCwgdGhlIElWUyBrbm93cyBp ZiB0aGUgUFNBUCByZWNlaXZlZDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwO3RoZSBNU0QsIGFuZCBjYW4gaW5mb3JtIHRoZSB2ZWhpY2xlIG9jY3VwYW50cyB0aGF0 IHRoZSBQU0FQPGJyPg0KJmd0OyZndDsmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7c3Vj Y2Vzc2Z1bGx5IHJlY2VpdmVkIHRoZSB2ZWhpY2xlIGxvY2F0aW9uIGFuZCBpbmZvcm1hdGlvbiBi dXQgY2FuJ3Q8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt0YWxr IHRvIHRoZSBvY2N1cGFudHMgYXQgdGhhdCB0aW1lLiZxdW90OyAtIHRoaXMgcHJldmVudHMgcGVy c29ucyBpbjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZndDsgdGhlIGNhciBmcm9tIGdldHRpbmcgZW1l cmdlbmN5IHNlcnZpY2Ugb2YgdGhlIFBTQVAgdXNpbmcgb3RoZXIgbWVhbnM8YnI+DQomZ3Q7Jmd0 OyZuYnNwOyAmZ3Q7IChlLmcuIHVzaW5nIGNpcmN1aXQgc3dpdGNoZWQgbmV0d29yaykuIFBvc3Np YmlsaXR5IGZvciBET1MgYXR0YWNrLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsg SWYgdGhlIFBTQVAgaXMgb3ZlcmxvYWRlZCAoZS5nLiwgdGhlcmUgaXMgYSB2ZXJ5IGxhcmdlIG11 bHRpLXZlaGljbGU8YnI+DQomZ3Q7Jmd0OyZuYnNwOyBpbmNpZGVudCwgb3IgYW5vdGhlciBsYXJn ZS1zY2FsZSBlbWVyZ2VuY3kgaW5jaWRlbnQpLCB0aGVuIHRoZXJlIGFyZSBsaWtlbHk8YnI+DQom Z3Q7Jmd0OyZuYnNwOyB0byBiZSBtdWx0aXBsZSBzaW11bHRhbmVvdXMgZUNhbGwgYXR0ZW1wdHMu Jm5ic3A7IFRoZSBkb2N1bWVudCBkb2VzIG5vdDxicj4NCiZndDsmZ3Q7IGluIGFueSB3YXk8YnI+ DQomZ3Q7Jmd0OyZuYnNwOyBkaWN0YXRlIG9yIG1hbmRhdGUgUFNBUCByZXNwb25zZS4mbmJzcDsg UFNBUHMgYXJlIGZyZWUgdG8gcmVzcG9uZCBhczxicj4NCiZndDsmZ3Q7IHRoZXkgY2hvb3NlLjxi cj4NCiZndDsmZ3Q7Jm5ic3A7IEUuZy4sIGEgUFNBUCBjYW4gYWNjZXB0IGVDYWxscyBhbmQgYWRk IHRoZW0gdG8gYSBxdWV1ZSwgYSBQU0FQIGNhbiByZWplY3QgYW48YnI+DQomZ3Q7Jmd0OyZuYnNw OyBlQ2FsbCBhbmQgaW5jbHVkZSBhbiBhY2sgd2l0aCAmcXVvdDtyZWNlaXZlZD1mYWxzZSZxdW90 OywgYSBQU0FQIGNhbiByZWplY3QgYW4gZUNhbGw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyBhbmQgaW5j bHVkZSBhbiBhY2sgd2l0aCAmcXVvdDtyZWNlaXZlZD10cnVlJnF1b3Q7LiZuYnNwOyBEb2luZyB0 aGUgbGF0dGVyPGJyPg0KJmd0OyZndDsgaW5kaWNhdGVzIHRoYXQgdGhlPGJyPg0KJmd0OyZndDsm bmJzcDsgUFNBUCBoYXMgcmVjZWl2ZWQgdGhlIE1TRCBhbmQgaGVuY2UgaXMgYXdhcmUgb2YgdGhl IGluY2lkZW50Ljxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7IEhvdyBjYW4gdGhlIFVBIGJlIHN1 cmUgdGhhdCBzdWNoIHJlc3BvbnNlIHdhcyBzZW50IGJ5IFBTQVAgYW5kIG5vdDxicj4NCiZndDsg YnkgYW4gYXR0YWNrZXIsIGxvY2F0ZWQgc29tZXdoZXJlIGJldHdlZW4gVUEgYW5kIFBTQVA/PGJy Pg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgQW55IFNJUCBlbnRpdHkgd2hpY2ggaGFwcGVucyB0byBi ZSBpbiB0aGUgcGF0aCBvZiB0aGUgZW1lcmdlbmN5PGJyPg0KJmd0OyBjYWxsIElOVklURSByZXF1 ZXN0IGNhbiBnZW5lcmF0ZSBhIDYwMCZuYnNwOyAoQnVzeSBFdmVyeXdoZXJlKSwgNDg2PGJyPg0K Jmd0OyAoQnVzeSBIZXJlKSwgYW5kIDYwMyAoRGVjbGluZSkgcmVzcG9uc2UgYW5kIHBvcHVsYXRl IGl0IHdpdGggYTxicj4NCiZndDsgcGFydGljdWxhciBib2R5Ljxicj4NCiZndDs8YnI+DQomZ3Q7 Jm5ic3A7IEl0IGlzIGF0IGxlYXN0IGEgc2VjdXJpdHkgcmlzayBhbmQgaXQgbmVlZHMgdG8gYmUg ZG9jdW1lbnRlZC48YnI+DQo8YnI+DQpPSywgSSdsbCBhZGQgc29tZSB0ZXh0Ljxicj4NCjxicj4N CiZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7Jm5ic3A7IElTU1VFIDExPGJyPg0KJmd0OyZn dDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZndDsmbmJzcDsgJnF1b3Q7VGhlIGJv ZHkgZm9yIGFuIGVtZXJnZW5jeUNhbGxEYXRhLmVDYWxsLk1TRCBpbmZvIHBhY2thZ2UgaXMgYTxi cj4NCiZndDsmZ3Q7Jm5ic3A7ICZndDsgbXVsdGlwYXJ0IGJvZHkuJnF1b3Q7IC0gd2hpY2ggbXVs dGlwYXJ0IE1JTUUgdHlwZSBpcyBtZWFudD88YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7IG11bHRp cGFydC9taXhlZCBvciBtdWx0aXBhcnQvYWx0ZXJuYXRpdmUgb3IgLi4uLjxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmbmJzcDsgV2UgZG8gbm90IG5lZWQgdG8gZ2V0IGludG8gdGhhdCBsZXZl bCBvZiBkZXRhaWwgaW4gdGhpcyB0ZXh0Ljxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7IElNTywg d2UgbmVlZCB0by4gRWxzZSwgdGhlIFVBIGNhbiBwcm92aWRlIG11bHRpcGFydC9taXhlZCB3aGls ZTxicj4NCiZndDsgUFNBUCBleHBlY3RzIG11bHRpcGFydC9hbHRlcm5hdGl2ZS48YnI+DQo8YnI+ DQpTYW1lIGFuc3dlciBhcyBhYm92ZS48YnI+DQo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsmbmJz cDsgJmd0OyZuYnNwOyBJU1NVRSAxNDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7 Jmd0OyZuYnNwOyAmZ3Q7Jm5ic3A7ICZxdW90O3doaWxlIG90aGVycyBjYW4gYmU8YnI+DQomZ3Q7 Jmd0OyZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtleHBlY3RlZCB0byBjYXJyeSBhbiBv Y2Nhc2lvbmFsIHJlcXVlc3QmcXVvdDsgLSBtZWFuaW5nIG9mICZxdW90O29jY2FzaW9uYWwmcXVv dDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7IGNhbiBiZSB3aGF0ZXZlciwgaXQgZGVwZW5kcyBv biBwZXJzcGVjdGl2ZSBvZiB0aGUgdXNlcjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZndDsgLSBvbmNl IHBlciBtaWxpc2Vjb25kLCBvbmNlIHBlciBzZWNvbmQsIG9uY2UgcGVyIG1pbnV0ZSwgb25jZSBw ZXIgaG91cjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZndDsgb3Igb25jZSBwZXIgZGF5Pzxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgT3RoZXIgdGV4dCBtYWtlcyBpdCBjbGVhciB0aGF0 IGEgcmVxdWVzdCBmb3IgYW4gdXBkYXRlZCBNU0QgaXM8YnI+DQomZ3Q7Jmd0OyBnZW5lcmFsbHkg c2VudDxicj4NCiZndDsmZ3Q7Jm5ic3A7IHVwb24gbWFudWFsIHJlcXVlc3Qgb2YgYSBQU0FQIGNh bGwgdGFrZXIgd2hvIHN1c3BlY3RzIHZlaGljbGU8YnI+DQomZ3Q7Jmd0OyBzdGF0ZSBtYXkgaGF2 ZSBjaGFuZ2VkLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7IEEgc3RhdGVtZW50IHRoYXQgdGhl IHJlcXVlc3QgaXMgZXhwZWN0ZWQgdG8gYmUgdHJpZ2dlcmVkIGJ5IG1hbnVhbDxicj4NCiZndDsg YWN0aW9uIG9mIHRoZSBQU0FQIGNhbGwgdGFrZXIgaXMgZ29vZCwgc28gSSBzdWdnZXN0IHRvIGFk ZCBpdCB0bzxicj4NCiZndDsgdGhpcyBzZWN0aW9uIHRvbyBhcyBleHBlcnQgcmV2aWV3ZXIgd2ls bCByZWFkIGl0Ljxicj4NCjxicj4NCk9LLCBJJ2xsIGFkZCB0ZXh0Ljxicj4NCjxicj4NCiZndDs8 YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJmd0OyZuYnNwOyBJ U1NVRSAxODxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmZ3Q7 Jm5ic3A7IEFjY2VwdCBpbiBGaWd1cmUgMTAgaXMgbm90IGNvcnJlY3QgLSBJTkZPIHJlc3BvbnNl IGlzIG5vdCBleHBlY3RlZDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZndDsgdG8gY29udGFpbiBib2R5 Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgRml4ZWQsIHRoYW5rcyBmb3IgY2F0 Y2hpbmcgdGhpcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyBpbiAtMTgsIEkgY2FuIHN0aWxs IHNlZSBBY2NlcHQgd2l0aCBtdWx0aXBhcnQvbWl4ZWQgaW4gdGhlIElORk88YnI+DQomZ3Q7IHJl cXVlc3QgaW4gRmlndXJlIDEwLjxicj4NCjxicj4NCkkgZG9uJ3Qgc2VlIGl0LiZuYnNwOyBIZXJl IGlzIEZpZ3VyZSAxMDo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO0lORk8gPGEgaHJl Zj0ibWFpbHRvOnNpcCUzQSUyQjEzMTQ1NTUxMTExQGV4YW1wbGUuY29tIj5zaXA6JiM0MzsxMzE0 NTU1MTExMUBleGFtcGxlLmNvbTwvYT4gU0lQLzIuMDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 VG86ICZsdDs8YSBocmVmPSJtYWlsdG86c2lwJTNBJTJCMTMxNDU1NTExMTFAZXhhbXBsZS5jb20i PnNpcDomIzQzOzEzMTQ1NTUxMTExQGV4YW1wbGUuY29tPC9hPiZndDs7dGFnPTlmeGNlZDc2c2w8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO0Zyb206IEV4ZW1wbGFyIFBTQVAgJmx0O3VybjpzZXJ2 aWNlOnNvcy5lY2FsbC5hdXRvbWF0aWMmZ3Q7O3RhZz04Z3lkZmU2NXQwPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDtDYWxsLUlEOiA8YSBocmVmPSJtYWlsdG86Mzg0ODI3NjI5ODIyMDE4ODUxMUBh dGxhbnRhLmV4YW1wbGUuY29tIj4zODQ4Mjc2Mjk4MjIwMTg4NTExQGF0bGFudGEuZXhhbXBsZS5j b208L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtDYWxsLUluZm86ICZsdDs8YSBocmVmPSJt YWlsdG86Y2lkJTNBMzQ1Njc4OTAxMkBhdGxhbnRhLmV4YW1wbGUuY29tIj5jaWQ6MzQ1Njc4OTAx MkBhdGxhbnRhLmV4YW1wbGUuY29tPC9hPiZndDs7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwdXJwb3NlPWVtZXJnZW5jeUNhbGxE YXRhLmNvbnRyb2w8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO0NTZXE6IDQxODYyIElORk88YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwO0luZm8tUGFja2FnZTogZW1lcmdlbmN5Q2FsbERhdGEuZUNh bGwuTVNEPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtBbGxvdzogSU5WSVRFLCBBQ0ssIFBSQUNL LCBJTkZPLCBPUFRJT05TLCBDQU5DRUwsIFJFRkVSLCBCWUUsPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU1VCU0NSSUJFLCBOT1RJRlksIFVQREFURTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7Q29udGVudC1UeXBlOiBtdWx0aXBhcnQvbWl4ZWQ7IGJvdW5k YXJ5PWJvdW5kYXJ5WlpaPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtDb250ZW50LURpc3Bvc2l0 aW86IEluZm8tUGFja2FnZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Q29udGVudC1MZW5ndGg6 IC4uLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7LS1ib3VuZGFyeVpaWjxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7Q29udGVudC1EaXNwb3NpdGlvbjogYnktcmVmZXJlbmNlPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDtDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2VtZXJnZW5jeUNh bGxEYXRhLmNvbnRyb2wmIzQzO3htbDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Q29udGVudC1J RDogJmx0OzxhIGhyZWY9Im1haWx0bzozNDU2Nzg5MDEyQGF0bGFudGEuZXhhbXBsZS5jb20iPjM0 NTY3ODkwMTJAYXRsYW50YS5leGFtcGxlLmNvbTwvYT4mZ3Q7PGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsmbHQ7P3htbCB2ZXJzaW9uPSZxdW90OzEuMCZxdW90OyBlbmNvZGluZz0mcXVv dDtVVEYtOCZxdW90Oz8mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7ZW1lcmdlbmN5 Q2FsbERhdGEuY29udHJvbDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt4 bWxucz0mcXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOkVtZXJnZW5jeUNhbGxEYXRhOmNvbnRy b2wmcXVvdDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7eG1sbnM6eHNp PSZxdW90OzxhIGhyZWY9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNl IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFu Y2U8L2E+JnF1b3Q7Jmd0Ozxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3JlcXVl c3QgYWN0aW9uPSZxdW90O3NlbmQtZGF0YSZxdW90OyBkYXRhdHlwZT0mcXVvdDtlQ2FsbC5NU0Qm cXVvdDsvJmd0Ozxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9lbWVyZ2VuY3lD YWxsRGF0YS5jb250cm9sJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IC0tYm91bmRhcnla WlotLTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RmlndXJlIDEwOiBJTkZP IHJlcXVlc3RpbmcgTVNEPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZn dDsmbmJzcDsgSU1PLCB0aGlzIGlzIHdyb25nIGFzIHdlIGRvIE5PVCBleHBlY3QgYSBib2R5IGlu IElORk8gcmVzcG9uc2UuPGJyPg0KJmd0OyBZZXMsIHRoZXJlIHdpbGwgYmUgYSBib2R5IGluIHN1 YnNlcXVlbnQgSU5GTyByZXF1ZXN0IHNlbnQgaW48YnI+DQomZ3Q7IG9wcG9zaXRlIGRpcmVjdGlv biwgYnV0IHRoYXQncyBub3QgaW1wYWN0ZWQgYnkgQWNjZXB0IGluIGZpcnN0IElORk88YnI+DQom Z3Q7IHJlcXVlc3QuPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7 Jmd0OyZuYnNwOyAmZ3Q7Jm5ic3A7IElTU1VFIDIwPGJyPg0KJmd0OyZndDsmbmJzcDsgJmd0Ozxi cj4NCiZndDsmZ3Q7Jm5ic3A7ICZndDsmbmJzcDsgZXhhbXBsZXMgY29udGFpbiBhIHZhbHVlIG9m IHNjaGVtYUxvY2F0aW9uIHBhcmFtZXRlciB3aGljaCBpcyBub3Q8YnI+DQomZ3Q7Jmd0OyZuYnNw OyAmZ3Q7IGFsaWduZWQgd2l0aCA8YSBocmVmPSJodHRwczovL3d3dy53My5vcmcvVFIveG1sc2No ZW1hLTAvI3NjaGVtYUxvY2F0aW9uIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy53My5v cmcvVFIveG1sc2NoZW1hLTAvI3NjaGVtYUxvY2F0aW9uPC9hPjxicj4NCiZndDsmZ3Q7Jm5ic3A7 ICZndDsgc3RhdGluZyAmcXVvdDtUaGUgc2NoZW1hTG9jYXRpb24gYXR0cmlidXRlIHZhbHVlIGNv bnNpc3RzIG9mIG9uZSBvciBtb3JlPGJyPg0KJmd0OyZndDsmbmJzcDsgJmd0OyBwYWlycyBvZiBV UkkgcmVmZXJlbmNlcywgc2VwYXJhdGVkIGJ5IHdoaXRlIHNwYWNlLiAmcXVvdDs8YnI+DQomZ3Q7 Jmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3hzaTpzY2hlbWFMb2NhdGlvbj08YnI+DQom Z3Q7Jmd0OyZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOkVtZXJn ZW5jeUNhbGxEYXRhOmNvbnRyb2wmcXVvdDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jm5i c3A7IEZpeGVkLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7IEkgY2FuIHNlZSBpbiAtMTgsIHRo YXQgeW91IGNob3NlIHRvIHJlbW92ZSB0aGUgaW5mb3JtYXRpb24gYWJvdXQ8YnI+DQomZ3Q7IHNj aGVtYSBsb2NhdGlvbiBmcm9tIHRoZSBYTUwgZXhhbXBsZXMuPGJyPg0KJmd0OyZuYnNwOyBUaGF0 J3MgT0sgd2l0aCBtZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyBIb3dldmVyLCB0aGVuIHlv dSBjYW4gYWxzbyByZW1vdmUgdGhlIGZvbGxvd2luZyBhcyBpdCBpcyBub3QgbmVlZGVkIGFueSBt b3JlPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt4bWxuczp4 c2k9JnF1b3Q7PGEgaHJlZj0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFu Y2UiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0 YW5jZTwvYT4mcXVvdDs8YnI+DQo8YnI+DQpJJ3ZlIGFza2VkIEhhbm5lcyB0byB2ZXJpZnkgdGhl IFhNTCBzY2hlbWEgYW5kIGV4YW1wbGVzIGFzIHBhcnQgb2Y8YnI+DQpJRVRGIExhc3QgQ2FsbC48 YnI+DQo8YnI+DQotLTxicj4NClJhbmRhbGwgR2VsbGVuczxicj4NCk9waW5pb25zIGFyZSBwZXJz b25hbDsmbmJzcDsgJm5ic3A7IGZhY3RzIGFyZSBzdXNwZWN0OyZuYnNwOyAmbmJzcDsgSSBzcGVh ayBmb3IgbXlzZWxmIG9ubHk8YnI+DQotLS0tLS0tLS0tLS0tLSBSYW5kb21seSBzZWxlY3RlZCB0 YWc6IC0tLS0tLS0tLS0tLS0tLTxicj4NClF1ZXN0aW9uIEF1dGhvcml0eS4mbmJzcDsgVGhleSB1 c3VhbGx5IGtub3cgd2hlcmUgdGhlIGJhdGhyb29tIGlzLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLS1NVFYncyAnRGFyaWEnPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkVjcml0 IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyI+RWNyaXRA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9lY3JpdCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZWNyaXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B4BDB496FESESSMB209erics_-- From nobody Thu Oct 27 03:53:48 2016 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 108EE129D5F for ; Thu, 27 Oct 2016 03:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 pK6Yn0J53yEv for ; Thu, 27 Oct 2016 03:53:43 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 4F53E129D51 for ; Thu, 27 Oct 2016 03:53:43 -0700 (PDT) X-AuditID: c1b4fb30-b87ff70000000cb2-27-5811dcb40b4d Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 40.88.03250.4BCD1185; Thu, 27 Oct 2016 12:53:41 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 27 Oct 2016 12:53:40 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zR6M62/38yUd7n2GwPWh7YVnh7KHzdZ+wqGU7olgh1g=; b=jQnV+ML6BAA0lxiPlNV2zgAm86aZZxLfDNnmf6gY3Q2utrre7UmU9x9rOj0mqNrrq0FbpUec5heFPhbTG8K+gg6Y6PR9AgYz9N+vHuN/TbX+wZtiAS8BxJlLvqd1r8SX2vgXavAYx6A+dGBHVfF/Soq86JN919VedEt2jMpzKB4= Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) by AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.7; Thu, 27 Oct 2016 10:53:39 +0000 Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com ([10.169.153.136]) by AM5PR0701MB2468.eurprd07.prod.outlook.com ([10.169.153.136]) with mapi id 15.01.0693.009; Thu, 27 Oct 2016 10:53:39 +0000 From: Ivo Sedlacek To: Ivo Sedlacek , Randall Gellens , Az Mankin , "ecrit@ietf.org" Thread-Topic: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 Thread-Index: AQHSMEBfHZ0ruNnrl0GOIZSsfS0MJw== Date: Thu, 27 Oct 2016 10:53:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ivo.sedlacek@ericsson.com; x-originating-ip: [77.48.233.153] x-ms-office365-filtering-correlation-id: 79f6632d-9d87-4ceb-2644-08d3fe578243 x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2468; 7:BmEnMP5QokPSoNIh+aSL3NCzgI9pvNcQscXqZaOxL2TCI+a/0rGwtD1/5oFlmsEu5mCYSRi4IP24zj/0NYBW1nSNZa90Cqn1p/kjsImNZ3i8PibmNFkDKBfVI8NCjpzR873QbuLC1CDARr+QyM2Umb6KFG8f9udN6KGAdLZdwVSAgWZj2xWFGpyGjTS/gzP/WSCkgPt0nmWl5GOkdlaiv6Xh9Nl1FocFgupBoRFWWFuamuVYkROn8208hDd8Hj/sVj65ELiCv0T+8gKZdfPCPnPG9MF6bdvbLvwdKeQW9gtUwB4ObjJls4rVXXJ0UccXxU6ClycWpOSfqY7dUWKvaIrAugW6xEDB4NyizrU2elM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0701MB2468; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AM5PR0701MB2468; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2468; x-forefront-prvs: 0108A997B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(31014005)(51444003)(199003)(586003)(2906002)(102836003)(6116002)(3846002)(790700001)(76576001)(5890100001)(3280700002)(2501003)(106356001)(2950100002)(19580395003)(33656002)(15975445007)(5002640100001)(10400500002)(105586002)(2900100001)(77096005)(93886004)(122556002)(16236675004)(9686002)(87936001)(54356999)(230783001)(101416001)(76176999)(8676002)(97736004)(19617315012)(92566002)(86362001)(189998001)(7736002)(7906003)(50986999)(19625215002)(19300405004)(11100500001)(66066001)(106116001)(68736007)(3660700001)(7696004)(107886002)(74316002)(8936002)(81166006)(5001770100001)(81156014)(5660300001)(7846002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2468; H:AM5PR0701MB2468.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2468393E1BE05E5326401D40E5AA0AM5PR0701MB2468_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2016 10:53:38.9509 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2468 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHed733dxWi8eleVARHEXmZZlFWIQXShhEFAQlEeTMN5XUyd5l aR/SD8ncEDSn5Uy22VJXieQlNS/NFaZhhpZZbsvIe5cvli1LW23vBL/9zvmfc/7POTw8UtTB CeRl5ihpRY4sS8wVUNXJHUlR7Xbf5Oi2hsjYu5VdRGxR3Swn1jmvRgmktEvn8JGaTCuEtN0+ TZ0gzwgOpdFZmXm0YndciiCjRlVC5er70JWld8cL0Q0TUiM+D/A+6Ptp4KiRgCfCzQi0A04u Gwwi0Hweo9xVFC4lwT7hzwq1BKhvj1NsMIxgYtlJuqu4WALlbc88s/ywAcGnugWPsBXHQZm2 ysN+OB6WnYtelsC0oRGxFjtg2dbnYSFOgVlbs/dRtygYfar1CHwsA6d5jnAzwtvA+eKBh0kc AJMzeoLdCIOp5xXJsj8sTv/lsPVnwaX5zmHzoVBxU++9wDH4tdxFuM0A15HQ2FrswwpSmBux eIfKwdnl8jYfBFX5cw7b0IOg87WOYoVgqH/rQqzQwoXFvlqPhQjT0NB0HbG3CATHmxIvB8OC vZdThsJ0G7ZgWQ6tX1c9LMS+MFQ9Q7H5SDB0L3FZjoB64xdynYct08TGvAH53EP+DM2kZqfH xEhoReZ5hpHnSHJoZQv6/5362/5Ed6LF+UQrwjwk3iz8+AgniziyPCY/24qAR4r9hAabb7JI mCbLL6AV8nOKS1k0Y0VBPEocINxvnjotwukyJX2RpnNpxbpK8PiBhYivOmypfu+4ymxaKYhf G8/40HSqG7l8lyymWlSxc23MNvlwIG5QFX+kMuaC0Tz7Q5pQKh81rl7Lzq1JH7sc5ehP36WJ HBGGnHw5SJgsmqCwxwccoePa4pBBrvBb45bqo3tLdEMoqej+74kqpdmaGhhxxxhObk98MtU7 nKXN04spJkO2J5xUMLJ/AN0y30oDAAA= Archived-At: Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 10:53:46 -0000 --_000_AM5PR0701MB2468393E1BE05E5326401D40E5AA0AM5PR0701MB2468_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I checked -19 against the comments raised during WGLC. I am OK with resolution of ISSUE 4, ISSUE 6, ISSUE 10, ISSUE 11, ISSUE 14, = ISSUE 18. ISSUE 2 did not seem to be addressed. However, I can live with ISSUE 2 not = being addressed so you can mark the ISSUE 2 as withdrawn. ISSUE 7, ISSUE 20 have not been addressed - see below. A new ISSUE 21 was found in -19 - see below. On: > >> > ISSUE 7 > >> > > >> > section 6 - "The IVS then attaches an updated MSD to a SIP > >> > INFO request and sends it within the dialog." - what is meant b= y > >> > "attaching MSD to SIP INFO request"? > >> > >> I think that's made abundantly clear in the multiple earlier > >> instances in the same section that say "as a MIME body part". > > > > I do not really know what "attach body to SIP request" means. > > Likely, other readers will not know it either. > > > > A reference to a section defining how to "attach body to SIP request" > > would help. > > It's the same section, just a little bit before. I assume you refer -19 text stating: "[RFC7852] establishes a general mecha= nism for attaching blocks of data to a SIP emergency call." However, RC7852 contains only one occurence of "attach" and that's in Figur= e 6 (see below) and it seems to refer to anything else. +-----------+----------------------------+ | Token | Description | +-----------+----------------------------+ | Mobile | The device is able to move | | | at any time | | | | | Fixed | The device is not expected | | | to move unless the | | | service is relocated | | | | | Nomadic | The device is not expected | | | to change its point of | | | attachment while on a | | | call | | | | | Unknown | No information is known | | | about the service | | | mobility environment for | | | the device | +-----------+----------------------------+ Figure 6: Service Mobility Registry Or do you refer to anything else? A formal definition would help. > >> > > >> > ISSUE 20 > >> > > >> > examples contain a value of schemaLocation parameter which is not > >> > aligned with https://www.w3.org/TR/xmlschema-0/#schemaLocation > >> > stating "The schemaLocation attribute value consists of one or > >> more > pairs of URI references, separated by white space. " > >> > > >> > xsi:schemaLocation=3D > >> > "urn:ietf:params:xml:ns:EmergencyCallData:control" > >> > >> Fixed. > > > > I can see in -18, that you chose to remove the information about > > schema location from the XML examples. > > That's OK with me. > > > > However, then you can also remove the following as it is not needed > > any more > > > > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > > I've asked Hannes to verify the XML schema and examples as part of IETF L= ast Call. xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" is still in XML tex= t examples and there is no usage of "xsi" prefix. ISSUE 21: in in-dialog requests, the Request-URI is set to remote con= tact URI (in case of loose routing) or to the most top route URI (in case o= f strict routing) - see rfc3261 section 12.2.1.1. In both cases, it would b= e SIP URI and not URN as in Figure 11. Kind regards Ivo --_000_AM5PR0701MB2468393E1BE05E5326401D40E5AA0AM5PR0701MB2468_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I checked -19 against the co= mments raised during WGLC.

 

I am OK with resolution of I= SSUE 4, ISSUE 6, ISSUE 10, ISSUE 11, ISSUE 14, ISSUE 18.<= /p>

 

ISSUE 2 did not seem to be a= ddressed. However, I can live with ISSUE 2 not being addressed so you can m= ark the ISSUE 2 as withdrawn.

 

ISSUE 7, ISSUE 20 have not b= een addressed - see below.

 

A new ISSUE 21 was found in = -19  - see below.

 

On:

 

> >>  >&nbs= p; ISSUE 7

> >>  >

> >>  >&nbs= p; section 6 - "The IVS then attaches an updated MSD to a SIP

> >>  >&nbs= p;    INFO request and sends it within the dialog." - w= hat is meant by

> >>  > &qu= ot;attaching MSD to SIP INFO request"?

> >>

> >>  I think = that's made abundantly clear in the multiple earlier

> >> instances in t= he  same section that say "as a MIME body part".<= /span>

> ><= /p>

> >  I do not rea= lly know what "attach body to SIP request"  means.

> > Likely, other read= ers will not know it either.

> ><= /p>

> >  A reference = to a section defining how to "attach body to SIP request"

> > would help.

>

> It's the same section, = just a little bit before.

&= nbsp;

I assu= me you refer -19 text stating: "[RFC7852] establishes a general mechan= ism for attaching blocks of

 =   data to a SIP emergency call."

&= nbsp;

Howeve= r, RC7852 contains only one occurence of "attach" and that's in F= igure 6 (see below) and it seems to refer to anything else.

&= nbsp;

       &nb= sp;          +-----------&= #43;----------------------------+

       &nb= sp;          | Token &nbs= p;   | Description        = ;        |

       &nb= sp;          +-----------&= #43;----------------------------+

       &nb= sp;          | Mobile &nb= sp;  | The device is able to move |

       &nb= sp;          |  &nbs= p;        |   at any time = ;             |=

       &nb= sp;          |  &nbs= p;        |     = ;            &n= bsp;          |

       &nb= sp;          | Fixed &nbs= p;   | The device is not expected |

       &nb= sp;          |  &nbs= p;        |   to move unless t= he       |

       &nb= sp;          |  &nbs= p;        |   service is reloc= ated     |

       &nb= sp;          |  &nbs= p;        |     = ;            &n= bsp;          |

       &nb= sp;          | Nomadic &n= bsp; | The device is not expected |

       &nb= sp;          |  &nbs= p;        |   to change its po= int of   |

       &nb= sp;          |  &nbs= p;        |   attachment wh= ile on a    |

       &nb= sp;          |  &nbs= p;        |   call  =             &nb= sp;      |

       &nb= sp;          |  &nbs= p;        |     = ;            &n= bsp;          |

       &nb= sp;          | Unknown &n= bsp; | No information is known    |

       &nb= sp;          |  &nbs= p;        |   about the servic= e        |

       &nb= sp;          |  &nbs= p;        |   mobility environ= ment for |

       &nb= sp;          |  &nbs= p;        |   the device =             &nb= sp; |

       &nb= sp;          +-----------&= #43;----------------------------+

 

       &nb= sp;            Figur= e 6: Service Mobility Registry

&= nbsp;

&= nbsp;

Or do = you refer to anything else? A formal definition would help.

&= nbsp;

> >>  >

> >>  >&nbs= p; ISSUE 20

> >>  >

> >>  >&nbs= p; examples contain a value of schemaLocation parameter which is not 

> >> > aligned w= ith https://www.w3.org/TR= /xmlschema-0/#schemaLocation

> >>  > sta= ting "The schemaLocation attribute value consists of one or

> >> more  >= ; pairs of URI references, separated by white space. "

> >>  >

> >>  >&nbs= p;            xsi:sc= hemaLocation=3D

> >>  >&nbs= p;            &= nbsp;   "urn:ietf:params:xml:ns:EmergencyCallData:control&qu= ot;

> >>

> >>  Fixed.

> ><= /p>

> >  I can see in= -18, that you chose to remove the information about

> > schema location fr= om the XML examples.

> >  That's OK wi= th me.

> ><= /p>

> >  However, the= n you can also remove the following as it is not needed

> > any more

> ><= /p>

> >    =      xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"

>

> I've asked Hannes to ve= rify the XML schema and examples as part of IETF Last Call.

 

xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance= " is still in XML text examples and there is no usage of "xsi" prefix.

 

 

 

ISSUE 21: =

 

    &nbs= p;           in in-dialog= requests, the Request-URI is set to remote contact URI (in case of loose r= outing) or to the most top route URI (in case of strict routing) - see rfc3= 261 section 12.2.1.1. In both cases, it would be SIP URI and not URN as in Figure 11.

 

Kind regards

 

Ivo

 

 

--_000_AM5PR0701MB2468393E1BE05E5326401D40E5AA0AM5PR0701MB2468_-- From nobody Thu Oct 27 04:15:10 2016 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 2D0AE129602 for ; Thu, 27 Oct 2016 04:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 bPyuCb66fFqu for ; Thu, 27 Oct 2016 04:15:06 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 39ED6129A6F for ; Thu, 27 Oct 2016 04:15:02 -0700 (PDT) X-AuditID: c1b4fb3a-18c55980000078c6-45-5811e1b4d5b1 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 3F.AB.30918.4B1E1185; Thu, 27 Oct 2016 13:15:00 +0200 (CEST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 27 Oct 2016 13:14:57 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wOvzfIsWtb8ttgzpXwBICSsRD7D+jj7jtMR8N1TKBCs=; b=Ga8N7zO1t8tGPCpQva5mGhx91WOuBDZCMLiRB+KHH3/Nw2zulB/O1Hrld463PzRznkp7aTE25gHMA/ulPaBsEr4iwgjbUYIhJtIdjyrZmrl+wm2M2N0jDTE+H24aIhxK/O0wpDx30KeeOs10b4SVyfFtNf3sFqQa3naz8qMzWpY= Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) by AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.7; Thu, 27 Oct 2016 11:14:56 +0000 Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com ([10.169.153.136]) by AM5PR0701MB2468.eurprd07.prod.outlook.com ([10.169.153.136]) with mapi id 15.01.0693.009; Thu, 27 Oct 2016 11:14:56 +0000 From: Ivo Sedlacek To: Ivo Sedlacek , Randall Gellens , Az Mankin , "ecrit@ietf.org" Thread-Topic: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 Thread-Index: AQHSMENY/+/OpknTpkajcZ5bdMhwxA== Date: Thu, 27 Oct 2016 11:14:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ivo.sedlacek@ericsson.com; x-originating-ip: [77.48.233.153] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2468; 7:YlDtSZ5J9aVhbG7sUbTlosfuy7q0IJkYzOzMmvJRFBKzKJCcZ8wnZlZ7imlWFuid9DUjEP+wxva8J43xwq/0JCC7PTi1my5HbDEm08Auj2AYhq6sHPWKBnjBNGE/Xb1NyeF82lKT+2Mj1RoNDlPRI9H1KY5EKs/KGQTgucGWIoZY5BwLqlqqa+R3wyw6RZm9bAB4frXn3xGY7Hvfam1QL8Ia4mlen+k/4W3CPSPvZNjOs74OCjC3U0cXSJ+v+aWeAh0dJmiJYAynykLIY9DLocyZ1cVeYGBps0XhtHux/WJB2M6oxfE7xpV6hjYEqqVAUy2SSbfBprzhBxUahvLCiW8p+jwS9mrgNumdUQNk188= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(7916002)(189002)(31014005)(51444003)(199003)(2906002)(586003)(6116002)(102836003)(3846002)(790700001)(76576001)(3280700002)(5890100001)(2501003)(106356001)(19580395003)(2950100002)(33656002)(15975445007)(10400500002)(105586002)(2900100001)(5002640100001)(77096005)(93886004)(16236675004)(9686002)(122556002)(87936001)(54356999)(230783001)(101416001)(76176999)(8676002)(97736004)(19617315012)(92566002)(86362001)(189998001)(7736002)(7906003)(50986999)(19625215002)(19300405004)(11100500001)(66066001)(106116001)(68736007)(3660700001)(7696004)(107886002)(74316002)(8936002)(81166006)(5001770100001)(81156014)(5660300001)(7846002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2468; H:AM5PR0701MB2468.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 06634f7f-ebf8-4957-8671-08d3fe5a7ba4 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0701MB2468; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AM5PR0701MB2468; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2468; x-forefront-prvs: 0108A997B2 received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB246842C83C03D6EE01EAE802E5AA0AM5PR0701MB2468_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2016 11:14:56.1781 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2468 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHeXfOtqM0ep0zn6YfahBIl1UWoVZWULA+hH1zhNhWnlSam+xM STNQSFszw/tlUq6lNk0TbDZFjWmSJpbdUIiNWdNNkTIzGSplurPAb7/n/3+fKy9FCLu5Yipd raO1aqVKwgsm6+S2cwesX0Pkh6yWXTFNVT2cmALzDDfG5zWg04Ssx+jkyxobVziyLoebvEhc Cj6RQqvSs2ntwXhFcNpE3zI/0zmKbkwsePn56HYHMqAgCvBReGjo5RhQMCXEHQhe280kG4wg 8HV2+QMSlxAw3FuMWOcBB/SOVj4bjCFYGF7ibBbjYSmUWYe4m4YImxB8M88Sm0YojofSymo/ i/ApWPbNBVgKtff1G2WpjR57YNUo25QFWAGTnorAHLUkfHhV6Z82CCvB1+LxN0N4B/hG2/xM 4HD4Mt3AYTfC0Ng3TrAcBnPuv1z2fRKsFy9xWX03VNQ0+NcBbCbg2Vo7wQZ2HtgetwQqXYB7 i5ZAhgw87+wBXQNvF0cCHeJAXzbMZZP7EHR/MpKsEQnNE+v+sYWYhifthYg9hRicn+8GOBJm Hf3cUhRl3LIFyxoo/+HgGf3nCIE3ddMkq+8HU+8vHsv7oPnRPPGfx+xuzlbdhPitKIyhGSYj NTpaSmvTrzKMRi1V07pOtPGfBqxrcd1owHtmEGEKSbYJpl5guZCrzGZyMgYRUIREJHC5QuRC QYoyJ5fWai5rs1Q0M4giKFISLjjW4koU4lSljr5O05m09r/LoYLE+Ug0I45YsSTpwUweeR/r 0Ksdeneyo3Dq+FCC4SZEVcW1NZ1c6p5fufa8ZPJKmzdrfFw3eqs8ti9Z4fqoCK1+2V+T8NtW 9d1+J9F2Nr62pqA+ZXbO1Fb0Exf37wxtr3c3zA9F9SY4GU98bmRx3p9+S9fy+YK8+qcqpc1b BKvbJSSTpjy8l9Ayyn+ZJ3edSwMAAA== Archived-At: Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 11:15:09 -0000 --_000_AM5PR0701MB246842C83C03D6EE01EAE802E5AA0AM5PR0701MB2468_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (ISSUE 21 reformulated) Hello, I checked -19 against the comments raised during WGLC. I am OK with resolution of ISSUE 4, ISSUE 6, ISSUE 10, ISSUE 11, ISSUE 14, = ISSUE 18. ISSUE 2 did not seem to be addressed. However, I can live with ISSUE 2 not = being addressed so you can mark the ISSUE 2 as withdrawn. ISSUE 7, ISSUE 20 have not been addressed - see below. A new ISSUE 21 was found in -19 - see below. On: > >> > ISSUE 7 > >> > > >> > section 6 - "The IVS then attaches an updated MSD to a SIP > >> > INFO request and sends it within the dialog." - what is meant b= y > >> > "attaching MSD to SIP INFO request"? > >> > >> I think that's made abundantly clear in the multiple earlier > >> instances in the same section that say "as a MIME body part". > > > > I do not really know what "attach body to SIP request" means. > > Likely, other readers will not know it either. > > > > A reference to a section defining how to "attach body to SIP request" > > would help. > > It's the same section, just a little bit before. I assume you refer -19 text stating: "[RFC7852] establishes a general mecha= nism for attaching blocks of data to a SIP emergency call." However, RC7852 contains only one occurence of "attach" and that's in Figur= e 6 (see below) and it seems to refer to anything else. +-----------+----------------------------+ | Token | Description | +-----------+----------------------------+ | Mobile | The device is able to move | | | at any time | | | | | Fixed | The device is not expected | | | to move unless the | | | service is relocated | | | | | Nomadic | The device is not expected | | | to change its point of | | | attachment while on a | | | call | | | | | Unknown | No information is known | | | about the service | | | mobility environment for | | | the device | +-----------+----------------------------+ Figure 6: Service Mobility Registry Or do you refer to anything else? A formal definition would help. > >> > > >> > ISSUE 20 > >> > > >> > examples contain a value of schemaLocation parameter which is not > >> > aligned with https://www.w3.org/TR/xmlschema-0/#schemaLocation > >> > stating "The schemaLocation attribute value consists of one or > >> more > pairs of URI references, separated by white space. " > >> > > >> > xsi:schemaLocation=3D > >> > "urn:ietf:params:xml:ns:EmergencyCallData:control" > >> > >> Fixed. > > > > I can see in -18, that you chose to remove the information about > > schema location from the XML examples. > > That's OK with me. > > > > However, then you can also remove the following as it is not needed > > any more > > > > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > > I've asked Hannes to verify the XML schema and examples as part of IETF L= ast Call. xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" is still in XML tex= t examples and there is no usage of "xsi" prefix. ISSUE 21: Request-URI of SIP INFO request in Figure 11 (INFO urn:serv= ice:sos.ecall.automatic SIP/2.0) is incorrect. Reason: in in-dialog requests, the Request-URI is set to th= e remote contact URI (in case of loose routing) or to the most top route UR= I (in case of strict routing) - see rfc3261 section 12.2.1.1. The draft does NOT need so state how Request-URI in SIP INF= O request is set, but the Request-URI of SIP INFO request in Figure 11 nee= ds to be corrected. Kind regards Ivo --_000_AM5PR0701MB246842C83C03D6EE01EAE802E5AA0AM5PR0701MB2468_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(ISSUE 2= 1 reformulated)

 

Hello,

 

I checked -19 against the co= mments raised during WGLC.

 

I am OK with resolution of I= SSUE 4, ISSUE 6, ISSUE 10, ISSUE 11, ISSUE 14, ISSUE 18.<= /p>

 

ISSUE 2 did not seem to be a= ddressed. However, I can live with ISSUE 2 not being addressed so you can m= ark the ISSUE 2 as withdrawn.

 

ISSUE 7, ISSUE 20 have not b= een addressed - see below.

 

A new ISSUE 21 was found in = -19  - see below.

 

On:

 

> >>  >&nbs= p; ISSUE 7

> >>  >

> >>  >&nbs= p; section 6 - "The IVS then attaches an updated MSD to a SIP

> >>  >&nbs= p;    INFO request and sends it within the dialog." - w= hat is meant by

> >>  > &qu= ot;attaching MSD to SIP INFO request"?

> >>

> >>  I think = that's made abundantly clear in the multiple earlier

> >> instances in t= he  same section that say "as a MIME body part".<= /span>

> ><= /p>

> >  I do not rea= lly know what "attach body to SIP request"  means.

> > Likely, other read= ers will not know it either.

> ><= /p>

> >  A reference = to a section defining how to "attach body to SIP request"

> > would help.

>

> It's the same section, = just a little bit before.

&= nbsp;

I assu= me you refer -19 text stating: "[RFC7852] establishes a general mechan= ism for attaching blocks of

 =   data to a SIP emergency call."

&= nbsp;

Howeve= r, RC7852 contains only one occurence of "attach" and that's in F= igure 6 (see below) and it seems to refer to anything else.

&= nbsp;

       &nb= sp;          +-----------&= #43;----------------------------+

       &nb= sp;          | Token &nbs= p;   | Description        = ;        |

       &nb= sp;          +-----------&= #43;----------------------------+

       &nb= sp;          | Mobile &nb= sp;  | The device is able to move |

       &nb= sp;          |  &nbs= p;        |   at any time = ;             |=

       &nb= sp;          |  &nbs= p;        |     = ;            &n= bsp;          |

       &nb= sp;          | Fixed &nbs= p;   | The device is not expected |

       &nb= sp;          |  &nbs= p;        |   to move unless t= he       |

       &nb= sp;          |  &nbs= p;        |   service is reloc= ated     |

       &nb= sp;          |  &nbs= p;        |     = ;            &n= bsp;          |

       &nb= sp;          | Nomadic &n= bsp; | The device is not expected |

       &nb= sp;          |  &nbs= p;        |   to change its po= int of   |

       &nb= sp;          |  &nbs= p;        |   attachment wh= ile on a    |

       &nb= sp;          |  &nbs= p;        |   call  =             &nb= sp;      |

       &nb= sp;          |  &nbs= p;        |     = ;            &n= bsp;          |

       &nb= sp;          | Unknown &n= bsp; | No information is known    |

       &nb= sp;          |  &nbs= p;        |   about the servic= e        |

       &nb= sp;          |  &nbs= p;        |   mobility environ= ment for |

       &nb= sp;          |  &nbs= p;        |   the device =             &nb= sp; |

       &nb= sp;          +-----------&= #43;----------------------------+

 

       &nb= sp;            Figur= e 6: Service Mobility Registry

&= nbsp;

&= nbsp;

Or do = you refer to anything else? A formal definition would help.

&= nbsp;

> >>  >

> >>  >&nbs= p; ISSUE 20

> >>  >

> >>  >&nbs= p; examples contain a value of schemaLocation parameter which is not 

> >> > aligned w= ith https://www.w3.org/TR= /xmlschema-0/#schemaLocation

> >>  > sta= ting "The schemaLocation attribute value consists of one or

> >> more  >= ; pairs of URI references, separated by white space. "

> >>  >

> >>  >&nbs= p;            xsi:sc= hemaLocation=3D

> >>  >&nbs= p;            &= nbsp;   "urn:ietf:params:xml:ns:EmergencyCallData:control&qu= ot;

> >>

> >>  Fixed.

> ><= /p>

> >  I can see in= -18, that you chose to remove the information about

> > schema location fr= om the XML examples.

> >  That's OK wi= th me.

> ><= /p>

> >  However, the= n you can also remove the following as it is not needed

> > any more

> ><= /p>

> >    =      xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"

>

> I've asked Hannes to ve= rify the XML schema and examples as part of IETF Last Call.

 

xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance= " is still in XML text examples and there is no usage of "xsi" prefix.

 

 

 

ISSUE 21: =

 

    &nbs= p;           Request-URI of SIP INFO request in Figure 11 (INFO urn:service:sos.ecall.au= tomatic SIP/2.0) is incorrect.

&nb= sp;

 &n= bsp;            = ;  Reason: in in-dialog requests, the Requ= est-URI is set to the remote contact URI (in case of loose r= outing) or to the most top route URI (in case of strict routing) - see rfc3= 261 section 12.2.1.1.

 

 &n= bsp;            = ;  The draft does NOT need so state how Request-URI in SIP INFO reques= t is set,  but the Request-URI of SIP INFO request in Figure 11 needs = to be corrected.

 

Kind regards

 

Ivo

 

 

--_000_AM5PR0701MB246842C83C03D6EE01EAE802E5AA0AM5PR0701MB2468_-- From nobody Thu Oct 27 04:41:10 2016 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 33E3C1294CE for ; Thu, 27 Oct 2016 04:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 OWSzfWSf73Jc for ; Thu, 27 Oct 2016 04:41:07 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 1B2DD1294AC for ; Thu, 27 Oct 2016 04:41:06 -0700 (PDT) X-AuditID: c1b4fb25-d35ee98000001e3e-3d-5811e7d18723 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id A6.B0.07742.1D7E1185; Thu, 27 Oct 2016 13:41:05 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Thu, 27 Oct 2016 13:40:56 +0200 From: Christer Holmberg To: Ivo Sedlacek , Randall Gellens , Az Mankin , "ecrit@ietf.org" Thread-Topic: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 - Issue 7 Thread-Index: AQHSMEb70gkIYMY9/026WKP1K8vLfg== Date: Thu, 27 Oct 2016 11:40:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D437C1F911E9Bchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7tO7F54IRBj/3ylksnbqTyaJx0VNW i+/PuxgdmD12zrrL7rFkyU8mj613HrMEMEdx2aSk5mSWpRbp2yVwZfRMnche8Ne64trMi6wN jHOMuxg5OSQETCRO7L/K1sXIxSEksJ5RonX6CiaQhJDAEkaJWVvDuhg5ONgELCS6/2mD1IgI LGCUeLToBTNIjbCAh8SM+RPZQGpEBDwlTh/RAgmLCOhJNH/8wQpiswioSkxaMYsFxOYVsJY4 37qSEcRmFBCT+H5qDdgqZgFxiVtP5jNB3CMgsWTPeWYIW1Ti5eN/rCDjRYFmrrkfBhFWlPj4 ah8jRGuCxIbDK1ghxgtKnJz5hGUCo9AsJFNnISmbhaQMIm4g8f7cfGYIW1ti2cLXULa+xMYv ZxkhbGuJaf9PsiGrWcDIsYpRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMJ4ObvmtuoPx8hvH Q4wCHIxKPLwPtglECLEmlhVX5h5ilOBgVhLhnfJEMEKINyWxsiq1KD++qDQntfgQozQHi5I4 r9nK++FCAumJJanZqakFqUUwWSYOTqkGxtxHW47f8d+0vn9vlpKXVsQ2DT1JyYa2E5GxD3LX uB8TKnl1O9lmwYo9Gpd/WpzLCuGorw35W7bwsdnGlSuMf51oiSk8XGRUsOd/U9GVtp46bt72 9ue5M923/dH8YiO2y2uB+69d7w9M1pSZ/qSpPuhTisHtB48t1pg+U5cOWiT0S2CC4GTLvUos xRmJhlrMRcWJACpybBSjAgAA Archived-At: Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 - Issue 7 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 11:41:09 -0000 --_000_D437C1F911E9Bchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >> >> > ISSUE 7 >> >> > >> >> > section 6 - "The IVS then attaches an updated MSD to a SIP >> >> > INFO request and sends it within the dialog." - what is meant = by >> >> > "attaching MSD to SIP INFO request"? >> >> >> >> I think that's made abundantly clear in the multiple earlier >> >> instances in the same section that say "as a MIME body part". >> > >> > I do not really know what "attach body to SIP request" means. >> > Likely, other readers will not know it either. >> > >> > A reference to a section defining how to "attach body to SIP request" >> > would help. >> >> It's the same section, just a little bit before. > >I assume you refer -19 text stating: "[RFC7852] establishes a general mech= anism for attaching blocks of > data to a SIP emergency call." I think we could say something like: =93[RFC7852] provides the general guidelines for including emergency call r= elated data in SIP messages=94 Then, wherever the text talks about =93attaching=94 data to a SIP message, = you use similar terminology: E.g., "encoding it per Annex A of EN 15722 [msd] and attaching it to a SIP message as a MIME body part per [RFC7852].=94 =85becomes: "encoding it per Annex A of EN 15722 [msd] and including it in a SIP message as a MIME body part per [RFC7852]. " Regards, Christer --_000_D437C1F911E9Bchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

>> >>  >  IS= SUE 7

>> >>  >=

>> >>  >=   section 6 - "The IVS then attaches an updated MSD to a SIP=

>> >>  >=      INFO request and sends it within the dialog."= - what is meant by

>> >>  >= "attaching MSD to SIP INFO request"?

>> >>=

>> >>  I th= ink that's made abundantly clear in the multiple earlier

>> >> instances = in the  same section that say "as a MIME body part".

>> >

>> >  I do not= really know what "attach body to SIP request"  means.

>> > Likely, other = readers will not know it either.

>> >

>> >  A refere= nce to a section defining how to "attach body to SIP request"

>> > would help.

>> <= /p>

>> It's the same secti= on, just a little bit before.

&= gt; 

>I = assume you refer -19 text stating: "[RFC7852] establishes a general me= chanism for attaching blocks of

> &= nbsp; data to a SIP emergency call."

&= nbsp;
I think we could say something like:

=93[RFC7852] provides the general guidelines for including emergency c= all related data in SIP messages=94

Then, wherever the text talks about =93attaching=94 data to a SIP mess= age, you use similar terminology:

E.g.,

   "encoding it per Annex A of EN 15722 [msd] and attac= hing it to a SIP
   message as a MIME body part per [RFC7852].=94

=85becomes:

   "encoding it per Annex A of EN 15722 [msd] and inclu= ding it in a SIP
   message as a MIME body part per [RFC7852]. "

Regards,

Christer


--_000_D437C1F911E9Bchristerholmbergericssoncom_-- From nobody Thu Oct 27 12:08:22 2016 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 C39B61295C4 for ; Thu, 27 Oct 2016 12:08:21 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 U-jQXgU89UaF for ; Thu, 27 Oct 2016 12:08:19 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA461296ED for ; Thu, 27 Oct 2016 12:08:06 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 27 Oct 2016 12:08:05 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Thu, 27 Oct 2016 12:08:03 -0700 To: Ivo Sedlacek , "ecrit@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 19:08:22 -0000 At 11:14 AM +0000 10/27/16, Ivo Sedlacek wrote: > (ISSUE 21 reformulated) > > Hello, > > I checked -19 against the comments raised during WGLC. > > I am OK with resolution of ISSUE 4, ISSUE 6, ISSUE 10, ISSUE 11, > ISSUE 14, ISSUE 18. > > ISSUE 2 did not seem to be addressed. However, I can live with > ISSUE 2 not being addressed so you can mark the ISSUE 2 as > withdrawn. > > ISSUE 7, ISSUE 20 have not been addressed - see below. > > A new ISSUE 21 was found in -19 - see below. > > On: > > > >> > ISSUE 7 > > >> > > > >> > section 6 - "The IVS then attaches an updated MSD to a SIP > > >> > INFO request and sends it within the dialog." - what is meant by > > >> > "attaching MSD to SIP INFO request"? > > >> > > >> I think that's made abundantly clear in the multiple earlier > > >> instances in the same section that say "as a MIME body part". > > > > > > I do not really know what "attach body to SIP request" means. > > > Likely, other readers will not know it either. > > > > > > A reference to a section defining how to "attach body to SIP request" > > > would help. > > > > It's the same section, just a little bit before. > > I assume you refer -19 text stating: "[RFC7852] establishes a > general mechanism for attaching blocks of > data to a SIP emergency call." If you look seven paragraphs above the paragraph in question (same section), you'll see: A PSAP or IVS transmits a metadata/control object (see Section 9) by encoding it per the description in this document and attaching it to a SIP message as a MIME body part per [RFC7852]. Then, three paragraphs later (four paragraphs above the paragraph in question) it uses "attach" again: An In-Vehicle System (IVS) initiating an NG-eCall attaches an MSD to the initial INVITE and optionally attaches a metadata/control object informing the PSAP of its capabilities. The surrounding text makes it clear that these are "attached" as body parts in the SIP message. > > However, RC7852 contains only one occurence of "attach" and that's > in Figure 6 (see below) and it seems to refer to anything else. > > +-----------+----------------------------+ > | Token | Description | > +-----------+----------------------------+ > | Mobile | The device is able to move | > | | at any time | > | | | > | Fixed | The device is not expected | > | | to move unless the | > | | service is relocated | > | | | > | Nomadic | The device is not expected | > | | to change its point of | > | | attachment while on a | > | | call | > | | | > | Unknown | No information is known | > | | about the service | > | | mobility environment for | > | | the device | > +-----------+----------------------------+ > > Figure 6: Service Mobility Registry > > > Or do you refer to anything else? A formal definition would help. > > > >> > > > >> > ISSUE 20 > > >> > > > >> > examples contain a value of schemaLocation parameter which is not > > >> > aligned with > > https://www.w3.org/TR/xmlschema-0/#schemaLocation > > >> > stating "The schemaLocation attribute value consists of one or > > >> more > pairs of URI references, separated by white space. " > > >> > > > >> > xsi:schemaLocation= > > >> > "urn:ietf:params:xml:ns:EmergencyCallData:control" > > >> > > >> Fixed. > > > > > > I can see in -18, that you chose to remove the information about > > > schema location from the XML examples. > > > That's OK with me. > > > > > > However, then you can also remove the following as it is not needed > > > any more > > > > > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > > > > I've asked Hannes to verify the XML schema and examples as part > of IETF Last Call. > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > is still in XML text examples and there is no usage of "xsi" prefix. > > > > ISSUE 21: > > Request-URI of SIP INFO request in Figure 11 (INFO > urn:service:sos.ecall.automatic SIP/2.0) is incorrect. > > Reason: in in-dialog requests, the Request-URI is > set to the remote contact URI (in case of loose routing) or to the > most top route URI (in case of strict routing) - see rfc3261 > section 12.2.1.1. > > The draft does NOT need so state how Request-URI in > SIP INFO request is set, but the Request-URI of SIP INFO request > in Figure 11 needs to be corrected. > > Kind regards > > Ivo > > -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I could never make out what those damned dots meant. --Lord Randolph Churchill, former Chancellor of the Exchequer, regarding decimal points From nobody Mon Oct 31 00:04:26 2016 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 66412129554 for ; Mon, 31 Oct 2016 00:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 RzTP7soGKT66 for ; Mon, 31 Oct 2016 00:04:24 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 AC952128E19 for ; Mon, 31 Oct 2016 00:04:23 -0700 (PDT) X-AuditID: c1b4fb2d-1dbff700000009f7-04-5816ecf50516 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id 57.D6.02551.5FCE6185; Mon, 31 Oct 2016 08:04:21 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 31 Oct 2016 08:04:21 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hjpdUmYMcwiCpitTMcttQ+YJgZRp02y2/NWe8OxhUY4=; b=HUD1vC+a9IqZp7hSv21mr4s3YiKAKj0HVYHXjdNushQ8mgIQDy1gaVWrSY5IT8g8O8K7NM8tN3QjIr4CAWcz+PEVvzSqm3aP6dEeeg0gvV7PjddAZcJCxmHHakpelPA9G99ex7SZbwvP8C3k8C26/9S8SHtRGhU/QIlQHZq3lcw= Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) by AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.1; Mon, 31 Oct 2016 07:04:20 +0000 Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com ([10.169.153.136]) by AM5PR0701MB2468.eurprd07.prod.outlook.com ([10.169.153.136]) with mapi id 15.01.0707.004; Mon, 31 Oct 2016 07:04:20 +0000 From: Ivo Sedlacek To: Randall Gellens , "ecrit@ietf.org" Thread-Topic: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 - ISSUE 7 Thread-Index: AdIzRCiPSesWv686Q3CGsB9ygk2d8w== Date: Mon, 31 Oct 2016 07:04:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ivo.sedlacek@ericsson.com; x-originating-ip: [193.179.210.162] x-ms-office365-filtering-correlation-id: f62dd7e9-5bb0-4200-aa6c-08d4015c2328 x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2468; 7:4VF6bhjDo2bWby7lsauKDBQqs8YAVa9SbYOZZc8iUbVBA7Z/DyOvgAd9A+kIm0+y0M29Apl97dVTBmCtvd+2i3KH0Xo46g1pdvt0p0L/Xla9EmWKm0zKSdFLahHTHJKZ7RSAsHQ5wjZijfjKB/SB8HqgbxmhCI+c5v1JKA799UUU7YKVvKbE5hV8539ObHK+Z8MGISQpKIoVGA+1qJkVQ2dqNoQoRf0v0nNa+I/xFfIFjlh32rhhK/0blI8bbnjYpTp9mcf0hOi70f/nrmK0LRNlwzmlpPQA8EeXSo7FjKi08iN7LOPeokw6nKWhR4G/1l2m3l6NwDssMK+t6GdFJ1Two4gJnfKpMK91CYdsyFc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0701MB2468; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM5PR0701MB2468; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2468; x-forefront-prvs: 01128BA907 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(5403001)(189002)(51444003)(199003)(5890100001)(2501003)(74316002)(107886002)(11100500001)(33656002)(586003)(92566002)(105586002)(8676002)(7846002)(2900100001)(305945005)(7736002)(106356001)(189998001)(81166006)(81156014)(5002640100001)(87936001)(3660700001)(230783001)(3280700002)(97736004)(5660300001)(76576001)(8936002)(5001770100001)(2906002)(66066001)(7696004)(9686002)(68736007)(77096005)(10400500002)(54356999)(50986999)(122556002)(101416001)(86362001)(102836003)(6116002)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2468; H:AM5PR0701MB2468.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2016 07:04:20.4188 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2468 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTURjGPfdju66GpzX1xTRoGYLlWhklEVIEtQjpS2hpkisvaulmu0tT KLSU3NRSs2BXxI9G0lIJ84uysGllFoq6rEwNcmaiaCghFmhu18D/nvM8v3N43pfDkLIbtB+T qDOyBp02SSGSUBZNc1DI7ykfjepN8Z6wrKoxOmx+3Iz2E2qrdYFQNw6NUseJKMm+ODYpMZU1 bA+PlSR0f5wmUnK8rtb314gzUcEaM/JkAO+C/qU50owkjAzXIfhjsyBXIMOdCDK/bnQFFC4g oWTATglUGQEjs1lIOHxAUHL7tdh1RYSVUNTQQZsRw8hxJGTPSFz2eqyGzvpblEvL8REYXigm BEQJY+UnXTaFt0Cvg3e/IsWx8LSUd5dA2Afmu2oIlyaxLww6ywmhNQZraw8paG+YGF2kBf4s LOXN0YK/GRqKZ1aYCCgbMIldlQFXkTD+Nl8kBGr40d3m7gNYD3mF1wU7GHI7eELgWxF8ds6J hcAfHCONSNAtNGS/X9kWC9W1OUiY1w+GHaYV7Q8/h17QwgDboOL5rEjQW+Fh5SRZiIL4VbPx qzB+Fca797IO3lmcVAWibMibYzkuOX5nqJI1JF7gOL1OqWON9Wj5Z7xq+BvSgh5PHrAjzCDF WqnqoI9GRmtTufRkOwKGVMilzollSxqnTc9gDfpzhitJLGdHGxhK4Svd/ejbaRmO1xrZSyyb whr+pwTj6ZeJ6E0Xm85HnjHdZAL6ujyi+bK2w6ovg5q7jUVe+fJTzz5JpId6RaXsHUdlbUxT WgWjPHr/V1TMkKW5NWDRGaJPtaXJpr5PTTeF14SdyB0wOuwPdBkl5BMtYZPbQ63tfR6BBROq dsO9JdPliKKWQKoqmrh2TNeTbS+tq345vleioLgE7Y5g0sBp/wGazqPrFQMAAA== Archived-At: Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 - ISSUE 7 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 07:04:25 -0000 Hello, > > > >> > ISSUE 7 > > > >> > > > > >> > section 6 - "The IVS then attaches an updated MSD to a SIP > > > >> > INFO request and sends it within the dialog." - what is m= eant by > > > >> > "attaching MSD to SIP INFO request"? > > > >> > > > >> I think that's made abundantly clear in the multiple earlier > > > >> instances in the same section that say "as a MIME body part". > > > > > > > > I do not really know what "attach body to SIP request" means. > > > > Likely, other readers will not know it either. > > > > > > > > A reference to a section defining how to "attach body to SIP req= uest" > > > > would help. > > > > > > It's the same section, just a little bit before. > > > > I assume you refer -19 text stating: "[RFC7852] establishes a general= =20 > > mechanism for attaching blocks of > > data to a SIP emergency call." >=20 > If you look seven paragraphs above the paragraph in question (same sectio= n),=20 > you'll see: >=20 > A PSAP or IVS transmits a metadata/control object (see Section 9) by > encoding it per the description in this document and attaching it to > a SIP message as a MIME body part per [RFC7852]. >=20 > Then, three paragraphs later (four paragraphs above the paragraph in > question) it uses "attach" again: >=20 > An In-Vehicle System (IVS) initiating an NG-eCall attaches an MSD to > the initial INVITE and optionally attaches a metadata/control object > informing the PSAP of its capabilities. >=20 > The surrounding text makes it clear that these are "attached" as body par= ts=20 > in the SIP message. The above still talks about "attaching"/"attaches" without explaining what = it means. It can be easily misunderstood to refer to inclusion of a body part with Co= ntent-Disposition "attachment" in a SIP message. Kind regards Ivo From nobody Mon Oct 31 11:08:53 2016 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 4A45212946F for ; Mon, 31 Oct 2016 11:08:51 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 ccT-3hvKVfZz for ; Mon, 31 Oct 2016 11:08:50 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id CD662129991 for ; Mon, 31 Oct 2016 11:08:48 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 31 Oct 2016 11:08:47 -0700 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Mon, 31 Oct 2016 11:06:14 -0700 To: Roger Marshall , Jeff Martin , Brian Rosen , ecrit@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: [Ecrit] Comments on draft-ietf-ecrit-similar-location-03 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 18:08:51 -0000 Hi Roger, Jeff, Brian, There's a typo in the second-to-last paragraph of Section 1: "protocol extension will protocol extension will". Also in the definition of "Civic Location": "to to". Also the definition of "Invalid Location" contains the term "findRequest" which I think should be "findService request". Also in section 3, "when invalid location is received" should perhaps be "invalid location elements are received". Also in section 4, consider using all uppercase forms of "optional" for clarity. I also think the definition of "Civic Location" could be made more clear (e.g., perhaps by mentioning that it is typically a street or postal address or part of one). I suggest rewording the second paragraph of section 4 to use descriptive rather than normative language, since "few" is not definable and hence the SHOULD NOT and MAY don't really seen appropriate. Consider mentioning if the additional elements can be returned only when validateLocation="true". -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- And still I persist in wondering if folly must always be man's nemesis. --Edgar Pangborn From nobody Mon Oct 31 11:08:58 2016 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 15EBF12946F for ; Mon, 31 Oct 2016 11:08:53 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 eqS22g5wVhUn for ; Mon, 31 Oct 2016 11:08:51 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B17C312999A for ; Mon, 31 Oct 2016 11:08:49 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 31 Oct 2016 11:08:48 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Mon, 31 Oct 2016 11:06:18 -0700 To: Dan Banks , "Rosen, Brian" , "ecrit@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Ecrit] draft-ietf-ecrit-similar-location-03 feedback - additional X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 18:08:53 -0000 Instead of a boolean, it might be worth considering an integer, to inform the client how many similar locations could match. Depending on the situation, the client might report an error and attempt to get a less ambiguous location. At 9:45 PM +0000 10/17/16, Dan Banks wrote: > I'm thinking of an example where you might a large apartment > building, and a query that did not include unit or floor. If the > response only lists the first 5 units as similar locations, a > person looking at this might (incorrectly) assume that the server > doesn't have data for the other 13 units in that building. Of > course, there is already a good disclaimer in the draft not to make > such assumptions, but the more often we can give the users a > complete list of similar locations, the more effective this > extension will be. So, I think an explicit indication will be > helpful. At the very least, it should save a support call or two > ("If the LVF knew that unit 501 was valid, then why did it only > suggest 101, 103, 201, 202, and 203?") > > Dan > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Monday, October 17, 2016 4:24 PM > To: Dan Banks; ecrit@ietf.org > Subject: Re: draft-ietf-ecrit-similar-location-03 feedback - additional > > I don't really have a problem with having this option, but one > question I have is what would the client do with that information? > I can't think of any behavior change that return of that > information would trigger. > > Brian > > From: Dan Banks <DBanks@ddti.net> > Date: Monday, October 17, 2016 at 4:18 PM > To: "ecrit@ietf.org" > <ecrit@ietf.org> > Cc: Brian Rosen <brian.rosen@neustar.biz> > Subject: draft-ietf-ecrit-similar-location-03 feedback - additional > > There is one thing I would like to add to the feedback which I sent > recently on the similar location draft: > > Section 4 discusses briefly the possibility of the server limiting > the number of returned similar locations. Although the current > text expresses the general idea that there may be a few that are > the "most likely" to be the correct location, there are also > scenarios where many similar locations could all be equally likely, > and the server might need to simply cut off the list at a > reasonable count. In those situations, I believe it would be > helpful if the server indicated when such a limit is actually > applied. > > I suggest that an attribute be added to the locationValidation > element of the findService response, perhaps > rli:similarLocationsLimited, having a data type of boolean, with > instructions that a server SHOULD include this attribute if the > number of returned similar locations is limited due to > configuration or policy. > > Dan Banks > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Don't worry about what people think; they don't do it very often. From nobody Mon Oct 31 11:15:16 2016 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 2E5181299A3 for ; Mon, 31 Oct 2016 11:15:13 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 dvEiIvx6tXHt for ; Mon, 31 Oct 2016 11:15:12 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 257ED12946F for ; Mon, 31 Oct 2016 11:15:12 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 31 Oct 2016 11:15:11 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Mon, 31 Oct 2016 11:15:09 -0700 To: Dan Banks , "ecrit@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: "Rosen, Brian \(Brian.Rosen@neustar.biz\)" Subject: Re: [Ecrit] draft-ietf-ecrit-similar-location-03 feedback X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 18:15:13 -0000 At 9:06 PM +0000 10/6/16, Dan Banks wrote: > I have been working on an implementation of the similar location > mechanism described by draft-ietf-ecrit-similar-location-03, and > have some feedback: > > 1) > For completeLocation, the actual element name in the schema is > "completedlocation", with a 'd' and lowercase 'l'. It appears this > should be "completeLocation". There is also a use of > "completedLocation" on page 5 that should be changed. Also, there > will only be a single completeLocation returned. I agree; these should be addressed. > 2) > An element "returnedLocationResponse" is defined by the schema, but > not discussed in the text or illustrated in the examples: I agree, this should be addressed. > 3) > It is desirable to have away for a client to specifically request > RLI, instead of it being included any time that validation is > performed. Responses with multiple similar locations can quickly > become large compared to responses without RLI, and may also incur > additional processing cost at the server. This could be wasteful > if automated validation is being performed or if the RLI is > otherwise not understood or discarded. I suggest an attribute be > added to the findService request (perhaps rli:returnLocation) with > defined values of { "none" | "similar" | "complete" | "any" } to > indicate which return location types the client is interested in. > Further, I suggest that the server be restricted to including only > RLI types in the response that are requested, and that omitting the > attribute from the request is equivalent to > rli:returnLocation="none". This seems worth discussing. > 5) > I would like to suggest that each element that users the > locationInformation pattern should only represent one location. > That is, instead of a single similarLocation element containing > multiple civicAddress elements (as illustrated in the example), > multiple similarLocation elements should be used with each > containing a single civicAddress. This seems helpful. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- f u cn rd ths, itn tyg h myxbl cd.