From nobody Thu Jan 5 03:14:13 2017 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 7CB4212946E; Thu, 5 Jan 2017 03:13:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148361483847.20720.1815627449197698164.idtracker@ietfa.amsl.com> Date: Thu, 05 Jan 2017 03:13:58 -0800 Archived-At: Cc: draft-ietf-ecrit-car-crash.all@ietf.org, ietf@ietf.org, ecrit@ietf.org Subject: [Ecrit] Review of draft-ietf-ecrit-car-crash-20 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: Thu, 05 Jan 2017 11:13:58 -0000 Reviewer: Dan Romascanu Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ecrit-car-crash-20 Reviewer: Dan Romascanu Review Date: 2017-01-05 IETF LC End Date: 2017-01-06 IESG Telechat date: 2017-01-19 Summary: It's a good and useful document which needs to be read and understood together with the eCall document, and other relevant documents from EC, NENA, APCOT. There is at least one major issue that deserves discussion and clarification before approval, IMO. Major issues: 1. One aspect of the relationship with eCall is unclear to me. The Abstract says: > 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. Then in the Introduction: > 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), as described in [I-D.ietf-ecrit-ecall]. 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). and in Section 9: > This document extends [I-D.ietf-ecrit-ecall] by reusing the call set- up and other normative requirements with the exception that in this document, support for the eCall MSD is OPTIONAL and support for VEDS in REQUIRED. First of all it's not clear if by 'eCall document' what it's meant is the European document or draft-ietf-ecrit-ecall. Second it's not clear how the two IETF documents, both on standards track relate, when the status of the MSD and VEDS data sets are different. What would prevail? The IESG is asked to approve two document, both on standards track, with different and in this case contradictory content. If I am a car manufacturer, I would ask myself what support will be mandatory to implement? Or maybe there are different scenarios where the different data sets are recommended? But then should not support for both be mandatory to implement and optional to use, maybe per geographical area? After all vehicles cross borders, or are transported / exported over the seas nowadays. Minor issues: 1. In the Abstract: > ... this document specifies a different set of vehicle (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) ... Actually VEDS is not specified in this document, but by APCO and NENA and referred by this document. 2. In section 4: > In the paired model, the IVS uses a Bluetooth link with a previously- paired handset to establish an emergency call Is Bluetooth only an example, or only one standard way of establishing a paired communication in the legacy example? I suspect the later - so I suggest that the text is reformulated in this manner. 3. I am not an expert in this area but I wonder whether the initial values of the registry in 14.6 are aligned with car manufacturers standards. For example I am wondering if lamps that change colors should not be also included. 4. I am not an expert in this area but I wonder whether the initial values of the registry in 14.7 are aligned with car manufacturers standards. For example I am wondering why night-vision capability is provided only for the front cameras. Nits/editorial comments: 1. I believe that the European eCall requirements documents 16062 and 16072 need to be Informative References. 2. Add an informative reference for Bluetooth mentioned in Section 4. 3. Section 16 needs to be removed at publication. From nobody Thu Jan 5 07:18:07 2017 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 20628129B53; Thu, 5 Jan 2017 07:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 qzkaB_RvIJrS; Thu, 5 Jan 2017 07:18:03 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 546F01289C4; Thu, 5 Jan 2017 07:18:00 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 935F112F9125D; Thu, 5 Jan 2017 15:17:55 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v05FHtp5032435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Jan 2017 15:17:58 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v05FHNB5030626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jan 2017 15:17:51 GMT Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.138]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Thu, 5 Jan 2017 16:17:48 +0100 From: "Drage, Keith (Nokia - GB)" To: Dan Romascanu Thread-Topic: [Ecrit] Review of draft-ietf-ecrit-car-crash-20 Thread-Index: AQHSZ0Tk29gVnjfUIE+7CxWknwLodaEp55Rw Date: Thu, 5 Jan 2017 15:17:46 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADFD171A@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <148361483847.20720.1815627449197698164.idtracker@ietfa.amsl.com> In-Reply-To: <148361483847.20720.1815627449197698164.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-ecrit-car-crash.all@ietf.org" , "ietf@ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] Review of draft-ietf-ecrit-car-crash-20 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, 05 Jan 2017 15:18:06 -0000 I think the text you have highlighted is confusing. While car-crash may build on the internet-draft ecall to create another ser= vice, the service defined as ecall by EC and by the various European and 3G= PP standards does not require or have any dependence on car-crash at all (o= r indeed any relationship). I agree this does need to be clearer. Keith -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Dan Romascanu Sent: 05 January 2017 11:14 To: gen-art@ietf.org Cc: draft-ietf-ecrit-car-crash.all@ietf.org; ietf@ietf.org; ecrit@ietf.org Subject: [Ecrit] Review of draft-ietf-ecrit-car-crash-20 Reviewer: Dan Romascanu Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review = Team (Gen-ART) reviews all IETF documents being processed by the IESG for t= he IETF Chair. Please treat these comments just like any other last call c= omments. For more information, please see the FAQ at . Document: draft-ietf-ecrit-car-crash-20 Reviewer: Dan Romascanu Review Date: 2017-01-05 IETF LC End Date: 2017-01-06 IESG Telechat date: 2017-01-19 Summary: It's a good and useful document which needs to be read and understood toget= her with the eCall document, and other relevant documents from EC, NENA, AP= COT. There is at least one major issue that deserves discussion and clarifi= cation before approval, IMO.=20 Major issues: 1. One aspect of the relationship with eCall is unclear to me.=20 The Abstract says:=20 > 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.=20 Then in the Introduction:=20 > 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), as described in [I-D.ietf-ecrit-ecall]. 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).=20 and in Section 9:=20 > This document extends [I-D.ietf-ecrit-ecall] by reusing the call set- up and other normative requirements with the exception that in this document, support for the eCall MSD is OPTIONAL and support for VEDS in REQUIRED.=20 First of all it's not clear if by 'eCall document' what it's meant is the E= uropean document or draft-ietf-ecrit-ecall. Second it's not clear how the t= wo IETF documents, both on standards track relate, when the status of the M= SD and VEDS data sets are different. What would prevail? The IESG is asked = to approve two document, both on standards track, with different and in thi= s case contradictory content. If I am a car manufacturer, I would ask mysel= f what support will be mandatory to implement? Or maybe there are different= scenarios where the different data sets are recommended? But then should n= ot support for both be mandatory to implement and optional to use, maybe pe= r geographical area? After all vehicles cross borders, or are transported /= exported over the seas nowadays.=20 Minor issues: 1. In the Abstract:=20 > ... this document specifies a different set of vehicle (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) ... Actually VEDS is not specified in this document, but by APCO and NENA and r= eferred by this document.=20 2. In section 4:=20 > In the paired model, the IVS uses a Bluetooth link with a previously- paired handset to establish an emergency call Is Bluetooth only an example, or only one standard way of establishing a pa= ired communication in the legacy example? I suspect the later - so I sugges= t that the text is reformulated in this manner. 3. I am not an expert in this area but I wonder whether the initial values = of the registry in 14.6 are aligned with car manufacturers standards. For e= xample I am wondering if lamps that change colors should not be also includ= ed.=20 4. I am not an expert in this area but I wonder whether the initial values = of the registry in 14.7 are aligned with car manufacturers standards. For e= xample I am wondering why night-vision capability is provided only for the = front cameras.=20 Nits/editorial comments:=20 1. I believe that the European eCall requirements documents 16062 and 16072 need to be Informative References.=20 2. Add an informative reference for Bluetooth mentioned in Section 4. 3. Section 16 needs to be removed at publication. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Thu Jan 5 11:11:44 2017 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 7D3E212960F; Thu, 5 Jan 2017 11:11:39 -0800 (PST) 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: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 wn0q_OPDPrgZ; Thu, 5 Jan 2017 11:11:37 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B6D6D12962A; Thu, 5 Jan 2017 11:11:37 -0800 (PST) Received: from [192.168.202.67] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 5 Jan 2017 11:10:46 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <148361483847.20720.1815627449197698164.idtracker@ietfa.amsl.com> References: <148361483847.20720.1815627449197698164.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Thu, 5 Jan 2017 11:11:30 -0800 To: Dan Romascanu , 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: draft-ietf-ecrit-car-crash.all@ietf.org, ietf@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] Review of draft-ietf-ecrit-car-crash-20 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, 05 Jan 2017 19:11:39 -0000 Hi Dan, Thanks for your review. Please see in-line. At 3:13 AM -0800 1/5/17, Dan Romascanu wrote: > Reviewer: Dan Romascanu > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-ecrit-car-crash-20 > Reviewer: Dan Romascanu > Review Date: 2017-01-05 > IETF LC End Date: 2017-01-06 > IESG Telechat date: 2017-01-19 > > Summary: > > It's a good and useful document which needs to be read and understood > together with the eCall document, and other relevant documents from > EC, NENA, APCOT. There is at least one major issue that deserves > discussion and clarification before approval, IMO. > > Major issues: > > 1. One aspect of the relationship with eCall is unclear to me. > > The Abstract says: > >> 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. > > Then in the Introduction: > >> 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), as described in > [I-D.ietf-ecrit-ecall]. 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). > > and in Section 9: > >> This document extends [I-D.ietf-ecrit-ecall] by reusing the call > set- > up and other normative requirements with the exception that in > this > document, support for the eCall MSD is OPTIONAL and support for > VEDS > in REQUIRED. > > First of all it's not clear if by 'eCall document' what it's meant is > the European document or draft-ietf-ecrit-ecall. My understanding is that references are frowned upon in Abstracts, otherwise there would be a reference to the IETF eCall draft there. I did change "extension of the eCall document" to "extension of the IETF eCall document" to try and make this more clear. > Second it's not clear > how the two IETF documents, both on standards track relate, when the > status of the MSD and VEDS data sets are different. What would > prevail? The IESG is asked to approve two document, both on standards > track, with different and in this case contradictory content. If I am > a car manufacturer, I would ask myself what support will be mandatory > to implement? Or maybe there are different scenarios where the > different data sets are recommended? But then should not support for > both be mandatory to implement and optional to use, maybe per > geographical area? After all vehicles cross borders, or are > transported / exported over the seas nowadays. There is no conflict, as the eCall document applies to regions that adhere to the E.U. eCall system, and this document applies to other regions. I added the following sentence to the paragraphs in the Abstract and Introduction: A vehicle designed for multiple regions will comply with the document applicable to the region in which it is located. The eCall document already says (in Document Scope): Note that 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]), but this is out of scope of this document. > > Minor issues: > > 1. In the Abstract: > >> ... this document specifies a different set of vehicle (crash) > data, specifically, the Vehicle Emergency Data Set (VEDS) ... > > Actually VEDS is not specified in this document, but by APCO and NENA > and referred by this document. I'll change "specifies" to "specifies use of". > > 2. In section 4: > >> In the paired model, the IVS uses a Bluetooth link with a > previously- > paired handset to establish an emergency call > > Is Bluetooth only an example, or only one standard way of establishing > a paired communication in the legacy example? I suspect the later - so > I suggest that the text is reformulated in this manner. Ok, I changed it to "a local link (typically Bluetooth)". > 3. I am not an expert in this area but I wonder whether the initial > values of the registry in 14.6 are aligned with car manufacturers > standards. For example I am wondering if lamps that change colors > should not be also included. The goal is that the initial values capture values that are widely supported by vehicles and likely to be useful to PSAPs. > > 4. I am not an expert in this area but I wonder whether the initial > values of the registry in 14.7 are aligned with car manufacturers > standards. For example I am wondering why night-vision capability is > provided only for the front cameras. The values were picked based on what's most supported, but I will add rear and side night-vision to the initial values. > > > Nits/editorial comments: > > 1. I believe that the European eCall requirements documents 16062 and > 16072 need to be Informative References. EU eCall requirements are referenced in the eCall draft, which this draft normatively references, and are not directly used in this draft, so I don't see that it's useful to add them here. > 2. Add an informative reference for Bluetooth mentioned in Section 4. OK. > 3. Section 16 needs to be removed at publication. I'll add a note. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Experience should teach us to be most on our guard to protect liberty when the government's purposes are beneficent. Men born to freedom are naturally alert to repel invasion of their liberty by evil-minded rulers. The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. --Louis D. Brandeis From nobody Thu Jan 5 11:54:07 2017 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 27D41129601; Thu, 5 Jan 2017 11:53:50 -0800 (PST) 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 uqzIWByUQUtc; Thu, 5 Jan 2017 11:53:47 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 47A691295F9; Thu, 5 Jan 2017 11:53:47 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id a20so54752762qkc.1; Thu, 05 Jan 2017 11:53:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CWSEmcO15QnAGS0vUIq9UlHGkQ9Q9NEeOVLzflun/GM=; b=jUCoNtIt619o1juOirFsGNGb6KFiOcUpFnY/7O1RNwnBmecM2QdhUkqWI2KThG6q2L X1oS+x2n95uZDM3ZjqQnOLcbGUeDRghe7TXw+q+WmnkxsfpEAKInt4dJOQjX2Xn1M4Fc 1joxwNjN5UbcvfksEfW2NoHf/djULS6OgcZRdM499gz0C44WCYYx38C+nP4//jd7WBJI hHZ4qXCQrTBp5JV3/PrQoVlcw0qVISgytYvPD3zVfrGrWFVes45vYrOhzKumb03bopjs shhFvctChdufjC9YIAsUPmKKQbjsi6Z17FcmEfRpaIomod+zBvyREDHRcElKzQnrXvKo iQog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CWSEmcO15QnAGS0vUIq9UlHGkQ9Q9NEeOVLzflun/GM=; b=JnJObHEgdakdPu1dWsIExYZzsiwM9nZAsinwWS4LfPfnHTHI07xqkJGMsO5zezr8+o j80NbBgTmz4KJpG/QbdtjuH4J2vF8th8SKiuAqpNXIxu5KJeS6YD1HfihnUq9PKO7HuW Aiyp4nmAnOTS4ALrl/IoB9GDYZNxxELW6WPLXkXUUV34js6VAfuZCTu74k1uvCG55Xoo gyX7FR8a44gHWZLfmyvkF/sUi2ry8xumvJrOxm8C6PG7buh9Vg8TiKmg48V17RRowkZx v+5degE1FbhgLil9k1eXId6TjZxawAU98fLc33vdR0THf9Iq1Tg5H1dysgNHGuCsZsVI dkSQ== X-Gm-Message-State: AIkVDXJZqnqhmkKsuo2MUgctJjc74CTEFo4hg5xE5JLDZMz1vjY1wKRTa1a5yrX1AwCi8ilynbiYBn0hTPxpqA== X-Received: by 10.55.187.70 with SMTP id l67mr47270059qkf.43.1483646026191; Thu, 05 Jan 2017 11:53:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.40.114 with HTTP; Thu, 5 Jan 2017 11:53:45 -0800 (PST) In-Reply-To: References: <148361483847.20720.1815627449197698164.idtracker@ietfa.amsl.com> From: Dan Romascanu Date: Thu, 5 Jan 2017 21:53:45 +0200 Message-ID: To: Randall Gellens Content-Type: multipart/alternative; boundary=94eb2c042fb25d17f405455e42a9 Archived-At: Cc: gen-art , draft-ietf-ecrit-car-crash.all@ietf.org, ietf , ecrit@ietf.org Subject: Re: [Ecrit] Review of draft-ietf-ecrit-car-crash-20 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, 05 Jan 2017 19:53:50 -0000 --94eb2c042fb25d17f405455e42a9 Content-Type: text/plain; charset=UTF-8 Hi, Thanks for the quick answer and for addressing my comments. On respect to: > There is no conflict, as the eCall document applies to regions that adhere to the E.U. eCall system, and this document applies to other regions. I added the following sentence to the paragraphs in the Abstract and Introduction: A vehicle designed for multiple regions will comply with the document applicable to the region in which it is located. I do not believe that this is sufficiently clear. Do you mean here that this document applies to all regions that do not implement the eCall system? If so, please say it explicitely. Also, what does 'comply' mean? Is this about what is implemented in the software, or about what is activated? Without this clarification, your usage of MANDATORY and OPTIONAL keywords is fuzzy. Regards, Dan On Thu, Jan 5, 2017 at 9:11 PM, Randall Gellens wrote: > Hi Dan, > > Thanks for your review. Please see in-line. > > > At 3:13 AM -0800 1/5/17, Dan Romascanu wrote: > > Reviewer: Dan Romascanu >> Review result: Almost Ready >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-ietf-ecrit-car-crash-20 >> Reviewer: Dan Romascanu >> Review Date: 2017-01-05 >> IETF LC End Date: 2017-01-06 >> IESG Telechat date: 2017-01-19 >> >> Summary: >> >> It's a good and useful document which needs to be read and understood >> together with the eCall document, and other relevant documents from >> EC, NENA, APCOT. There is at least one major issue that deserves >> discussion and clarification before approval, IMO. >> >> Major issues: >> >> 1. One aspect of the relationship with eCall is unclear to me. >> >> The Abstract says: >> >> 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. >> >> Then in the Introduction: >> >> 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), as described in >> [I-D.ietf-ecrit-ecall]. 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). >> >> and in Section 9: >> >> This document extends [I-D.ietf-ecrit-ecall] by reusing the call >>> >> set- >> up and other normative requirements with the exception that in >> this >> document, support for the eCall MSD is OPTIONAL and support for >> VEDS >> in REQUIRED. >> >> First of all it's not clear if by 'eCall document' what it's meant is >> the European document or draft-ietf-ecrit-ecall. >> > > My understanding is that references are frowned upon in Abstracts, > otherwise there would be a reference to the IETF eCall draft there. I did > change "extension of the eCall document" to "extension of the IETF eCall > document" to try and make this more clear. > > Second it's not clear >> how the two IETF documents, both on standards track relate, when the >> status of the MSD and VEDS data sets are different. What would >> prevail? The IESG is asked to approve two document, both on standards >> track, with different and in this case contradictory content. If I am >> a car manufacturer, I would ask myself what support will be mandatory >> to implement? Or maybe there are different scenarios where the >> different data sets are recommended? But then should not support for >> both be mandatory to implement and optional to use, maybe per >> geographical area? After all vehicles cross borders, or are >> transported / exported over the seas nowadays. >> > > There is no conflict, as the eCall document applies to regions that adhere > to the E.U. eCall system, and this document applies to other regions. I > added the following sentence to the paragraphs in the Abstract and > Introduction: > > A vehicle designed for multiple regions will > comply with the document applicable to the region in which it is > located. > > The eCall document already says (in Document Scope): > > Note that 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]), but this > is out of scope of this document. > > > >> Minor issues: >> >> 1. In the Abstract: >> >> ... this document specifies a different set of vehicle (crash) >>> >> data, specifically, the Vehicle Emergency Data Set (VEDS) ... >> >> Actually VEDS is not specified in this document, but by APCO and NENA >> and referred by this document. >> > > I'll change "specifies" to "specifies use of". > > >> 2. In section 4: >> >> In the paired model, the IVS uses a Bluetooth link with a >>> >> previously- >> paired handset to establish an emergency call >> >> Is Bluetooth only an example, or only one standard way of establishing >> a paired communication in the legacy example? I suspect the later - so >> I suggest that the text is reformulated in this manner. >> > > Ok, I changed it to "a local link (typically Bluetooth)". > > 3. I am not an expert in this area but I wonder whether the initial >> values of the registry in 14.6 are aligned with car manufacturers >> standards. For example I am wondering if lamps that change colors >> should not be also included. >> > > The goal is that the initial values capture values that are widely > supported by vehicles and likely to be useful to PSAPs. > > >> 4. I am not an expert in this area but I wonder whether the initial >> values of the registry in 14.7 are aligned with car manufacturers >> standards. For example I am wondering why night-vision capability is >> provided only for the front cameras. >> > > The values were picked based on what's most supported, but I will add rear > and side night-vision to the initial values. > > >> >> Nits/editorial comments: >> >> 1. I believe that the European eCall requirements documents 16062 and >> 16072 need to be Informative References. >> > > EU eCall requirements are referenced in the eCall draft, which this draft > normatively references, and are not directly used in this draft, so I don't > see that it's useful to add them here. > > 2. Add an informative reference for Bluetooth mentioned in Section 4. >> > > OK. > > 3. Section 16 needs to be removed at publication. >> > > I'll add a note. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > Experience should teach us to be most on our guard to protect liberty > when the government's purposes are beneficent. Men born to freedom are > naturally alert to repel invasion of their liberty by evil-minded > rulers. The greatest dangers to liberty lurk in insidious encroachment > by men of zeal, well-meaning but without understanding. > --Louis D. Brandeis > --94eb2c042fb25d17f405455e42a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for = the quick answer and for addressing my comments.

On respect t= o:

> There is no conflict, as the eCall document applies to regi= ons that=20 adhere to the E.U. eCall system, and this document applies to other=20 regions.=C2=A0 I added the following sentence to the paragraphs in the=20 Abstract and Introduction:

=C2=A0 =C2=A0A vehicle designed for multiple regions will
=C2=A0 =C2=A0comply with the document applicable to the region in which it = is
=C2=A0 =C2=A0located.

I do not believe that this is sufficient= ly clear. Do you mean here that this document applies to all regions that d= o not implement the eCall system? If so, please say it explicitely.
Also, what does 'comply' mean? Is this about what is impleme= nted in the software, or about what is activated? Without this clarificatio= n, your usage of MANDATORY and OPTIONAL keywords is fuzzy.

Re= gards,

Dan


On Thu, Jan 5, 2017 at 9:11 PM, Randall Gellens <rg+i= etf@randy.pensive.org> wrote:
Hi Dan,

Thanks for your review.=C2=A0 Please see in-line.


At 3:13 AM -0800 1/5/17, Dan Romascanu wrote:

=C2=A0Reviewer: Dan Romascanu
=C2=A0Review result: Almost Ready

=C2=A0I am the assigned Gen-ART reviewer for this draft. The General Area =C2=A0Review Team (Gen-ART) reviews all IETF documents being processed
=C2=A0by the IESG for the IETF Chair.=C2=A0 Please treat these comments jus= t
=C2=A0like any other last call comments.

=C2=A0For more information, please see the FAQ at

=C2=A0<https://trac.ietf.org/trac/gen/wiki/GenA= rtfaq>.

=C2=A0Document: draft-ietf-ecrit-car-crash-20
=C2=A0Reviewer: Dan Romascanu
=C2=A0Review Date: 2017-01-05
=C2=A0IETF LC End Date: 2017-01-06
=C2=A0IESG Telechat date: 2017-01-19

=C2=A0Summary:

=C2=A0It's a good and useful document which needs to be read and unders= tood
=C2=A0together with the eCall document, and other relevant documents from =C2=A0EC, NENA, APCOT. There is at least one major issue that deserves
=C2=A0discussion and clarification before approval, IMO.

=C2=A0Major issues:

=C2=A01. One aspect of the relationship with eCall is unclear to me.

=C2=A0The Abstract says:

=C2=A0 This document is an extension
=C2=A0 =C2=A0 of the eCall document, with the primary differences being tha= t
=C2=A0this
=C2=A0 =C2=A0 document makes the MSD data set optional and VEDS mandatory, = and
=C2=A0adds
=C2=A0 =C2=A0 attribute values to the metadata/control object to permit gre= ater
=C2=A0 =C2=A0 functionality.

=C2=A0Then in the Introduction:

=C2=A0This 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), as described in =C2=A0 =C2=A0 [I-D.ietf-ecrit-ecall].=C2=A0 However, this document specifie= s a
=C2=A0different
=C2=A0 =C2=A0 set of vehicle (crash) data, specifically, the Vehicle Emerge= ncy
=C2=A0Data
=C2=A0 =C2=A0 Set (VEDS) rather than the eCall Minimum Set of Data (MSD).
=C2=A0and in Section 9:

=C2=A0 This document extends [I-D.ietf-ecrit-ecall] by reusing the call
=C2=A0set-
=C2=A0 =C2=A0 up and other normative requirements with the exception that i= n
=C2=A0this
=C2=A0 =C2=A0 document, support for the eCall MSD is OPTIONAL and support f= or
=C2=A0VEDS
=C2=A0 =C2=A0 in REQUIRED.

=C2=A0First of all it's not clear if by 'eCall document' what i= t's meant is
=C2=A0the European document or draft-ietf-ecrit-ecall.

My understanding is that references are frowned upon in Abstracts, otherwis= e there would be a reference to the IETF eCall draft there. I did change &q= uot;extension of the eCall document" to "extension of the IETF eC= all document" to try and make this more clear.<= br>
=C2=A0 Second it's not clear
=C2=A0how the two IETF documents, both on standards track relate, when the<= br> =C2=A0status of the MSD and VEDS data sets are different. What would
=C2=A0prevail? The IESG is asked to approve two document, both on standards=
=C2=A0track, with different and in this case contradictory content. If I am=
=C2=A0a car manufacturer, I would ask myself what support will be mandatory=
=C2=A0to implement? Or maybe there are different scenarios where the
=C2=A0different data sets are recommended? But then should not support for<= br> =C2=A0both be mandatory to implement and optional to use, maybe per
=C2=A0geographical area? After all vehicles cross borders, or are
=C2=A0transported / exported over the seas nowadays.

 There is no conflict, as the eCall document applies to regions that adhere = to the E.U. eCall system, and this document applies to other regions.=C2=A0= I added the following sentence to the paragraphs in the Abstract and Intro= duction:

=C2=A0 =C2=A0A vehicle designed for multiple regions will
=C2=A0 =C2=A0comply with the document applicable to the region in which it = is
=C2=A0 =C2=A0located.

The eCall document already says (in Document Scope):

=C2=A0 =C2=A0Note that vehicles designed for multiple regions might need to=
=C2=A0 =C2=A0support eCall and other Advanced Automatic Crash Notification = (AACN)
=C2=A0 =C2=A0systems (such as described in [I-D.ietf-ecrit-car-crash]), but= this
=C2=A0 =C2=A0is out of scope of this document.



=C2=A0Minor issues:

=C2=A01. In the Abstract:

=C2=A0... this document specifies a different set of vehicle (crash)
=C2=A0 =C2=A0 data, specifically, the Vehicle Emergency Data Set (VEDS) ...=

=C2=A0Actually VEDS is not specified in this document, but by APCO and NENA=
=C2=A0and referred by this document.

 I'll change "specifies" to "specifies use of".


=C2=A02. In section 4:

=C2=A0 In the paired model, the IVS uses a Bluetooth link with a
=C2=A0previously-
=C2=A0 =C2=A0 paired handset to establish an emergency call

=C2=A0Is Bluetooth only an example, or only one standard way of establishin= g
=C2=A0a paired communication in the legacy example? I suspect the later - s= o
=C2=A0I suggest that the text is reformulated in this manner.

Ok, I changed it to "a local link (typically Bluetooth)".

=C2=A03. I am not an expert in this area but I wonder whether the initial =C2=A0values of the registry in 14.6 are aligned with car manufacturers
=C2=A0standards. For example I am wondering if lamps that change colors
=C2=A0should not be also included.

 The goal is that the initial values capture values that are widely supporte= d by vehicles and likely to be useful to PSAPs.


=C2=A04. I am not an expert in this area but I wonder whether the initial =C2=A0values of the registry in 14.7 are aligned with car manufacturers
=C2=A0standards. For example I am wondering why night-vision capability is<= br> =C2=A0provided only for the front cameras.

 The values were picked based on what's most supported, but I will add r= ear and side night-vision to the initial values.



=C2=A0Nits/editorial comments:

=C2=A01. I believe that the European eCall requirements documents 16062 and=
=C2=A016072 need to be Informative References.

 EU eCall requirements are referenced in the eCall draft, which this draft n= ormatively references, and are not directly used in this draft, so I don= 9;t see that it's useful to add them here.

=C2=A02. Add an informative reference for Bluetooth mentioned in Section 4.=

OK.

=C2=A03. Section 16 needs to be removed at publication.

 I'll add a note.
--
Randall Gellens
Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak= for myself only
-------------- Randomly selected tag: ---------------
Experience should teach us to be most on our guard to protect liberty
when the government's purposes are beneficent.=C2=A0 Men born to freedo= m are
naturally alert to repel invasion of their liberty by evil-minded
rulers.=C2=A0 The greatest dangers to liberty lurk in insidious encroachmen= t
by men of zeal, well-meaning but without understanding.
=C2=A0 =C2=A0--Louis D. Brandeis

--94eb2c042fb25d17f405455e42a9-- From nobody Fri Jan 6 04:54:54 2017 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 60724129B0C; Fri, 6 Jan 2017 04:54:46 -0800 (PST) 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: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 o_JV3tmo4rne; Fri, 6 Jan 2017 04:54:45 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D80EE128AC9; Fri, 6 Jan 2017 04:54:44 -0800 (PST) Received: from [192.168.202.67] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 6 Jan 2017 04:53:46 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <148361483847.20720.1815627449197698164.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Fri, 6 Jan 2017 04:54:36 -0800 To: Dan Romascanu 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: gen-art , draft-ietf-ecrit-car-crash.all@ietf.org, ietf , ecrit@ietf.org Subject: Re: [Ecrit] Review of draft-ietf-ecrit-car-crash-20 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, 06 Jan 2017 12:54:46 -0000 At 9:53 PM +0200 1/5/17, Dan Romascanu wrote: > Hi, > > Thanks for the quick answer and for addressing my comments. > > On respect to: > >> There is no conflict, as the eCall document applies to regions >> that adhere to the E.U. eCall system, and this document applies to >> other regions. I added the following sentence to the paragraphs >> in the Abstract and Introduction: > > A vehicle designed for multiple regions will > comply with the document applicable to the region in which it is > located. > > I do not believe that this is sufficiently clear. Do you mean here > that this document applies to all regions that do not implement the > eCall system? If so, please say it explicitely. > > Also, what does 'comply' mean? Is this about what is implemented in > the software, or about what is activated? Without this > clarification, your usage of MANDATORY and OPTIONAL keywords is > fuzzy. Hi Dan, On reflection, I've deleted the two added sentences: A vehicle designed for multiple regions will comply with the document applicable to the region in which it is located. The Introduction already says: Vehicles designed to operate in multiple regions might need to support eCall as well as NG-ACN as described here. A vehicle IVS might determine whether to use eCall or ACN by first determining the region or country in which it is located (e.g., from a GNSS location estimate and/or identity of or information from an MNO). If other regions adopt other data formats, a multi-region vehicle might need to support those as well. I think this text is better than the added sentences, and I agree with you that the added text introduced its own ambiguity. --Randy > On Thu, Jan 5, 2017 at 9:11 PM, Randall Gellens > <rg+ietf@randy.pensive.org> wrote: > > Hi Dan, > > Thanks for your review. Please see in-line. > > > At 3:13 AM -0800 1/5/17, Dan Romascanu wrote: > > Reviewer: Dan Romascanu > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-ecrit-car-crash-20 > Reviewer: Dan Romascanu > Review Date: 2017-01-05 > IETF LC End Date: 2017-01-06 > IESG Telechat date: 2017-01-19 > > Summary: > > It's a good and useful document which needs to be read and understood > together with the eCall document, and other relevant documents from > EC, NENA, APCOT. There is at least one major issue that deserves > discussion and clarification before approval, IMO. > > Major issues: > > 1. One aspect of the relationship with eCall is unclear to me. > > The Abstract says: > > 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. > > Then in the Introduction: > > 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), as described in > [I-D.ietf-ecrit-ecall]. 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). > > and in Section 9: > > This document extends [I-D.ietf-ecrit-ecall] by reusing the call > > set- > up and other normative requirements with the exception that in > this > document, support for the eCall MSD is OPTIONAL and support for > VEDS > in REQUIRED. > > First of all it's not clear if by 'eCall document' what it's meant is > the European document or draft-ietf-ecrit-ecall. > > > My understanding is that references are frowned upon in Abstracts, > otherwise there would be a reference to the IETF eCall draft there. > I did change "extension of the eCall document" to "extension of the > IETF eCall document" to try and make this more clear. > > Second it's not clear > how the two IETF documents, both on standards track relate, when the > status of the MSD and VEDS data sets are different. What would > prevail? The IESG is asked to approve two document, both on standards > track, with different and in this case contradictory content. If I am > a car manufacturer, I would ask myself what support will be mandatory > to implement? Or maybe there are different scenarios where the > different data sets are recommended? But then should not support for > both be mandatory to implement and optional to use, maybe per > geographical area? After all vehicles cross borders, or are > transported / exported over the seas nowadays. > > > There is no conflict, as the eCall document applies to regions that > adhere to the E.U. eCall system, and this document applies to other > regions. I added the following sentence to the paragraphs in the > Abstract and Introduction: > > A vehicle designed for multiple regions will > comply with the document applicable to the region in which it is > located. > > The eCall document already says (in Document Scope): > > Note that 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]), but this > is out of scope of this document. > > > Minor issues: > > 1. In the Abstract: > > ... this document specifies a different set of vehicle (crash) > > data, specifically, the Vehicle Emergency Data Set (VEDS) ... > > Actually VEDS is not specified in this document, but by APCO and NENA > and referred by this document. > > > I'll change "specifies" to "specifies use of". > > > 2. In section 4: > > In the paired model, the IVS uses a Bluetooth link with a > > previously- > paired handset to establish an emergency call > > Is Bluetooth only an example, or only one standard way of establishing > a paired communication in the legacy example? I suspect the later - so > I suggest that the text is reformulated in this manner. > > > Ok, I changed it to "a local link (typically Bluetooth)". > > 3. I am not an expert in this area but I wonder whether the initial > values of the registry in 14.6 are aligned with car manufacturers > standards. For example I am wondering if lamps that change colors > should not be also included. > > > The goal is that the initial values capture values that are widely > supported by vehicles and likely to be useful to PSAPs. > > > 4. I am not an expert in this area but I wonder whether the initial > values of the registry in 14.7 are aligned with car manufacturers > standards. For example I am wondering why night-vision capability is > provided only for the front cameras. > > > The values were picked based on what's most supported, but I will > add rear and side night-vision to the initial values. > > > > Nits/editorial comments: > > 1. I believe that the European eCall requirements documents 16062 and > 16072 need to be Informative References. > > > EU eCall requirements are referenced in the eCall draft, which this > draft normatively references, and are not directly used in this > draft, so I don't see that it's useful to add them here. > > 2. Add an informative reference for Bluetooth mentioned in Section 4. > > > OK. > > 3. Section 16 needs to be removed at publication. > > > I'll add a note. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > Experience should teach us to be most on our guard to protect liberty > when the government's purposes are beneficent. Men born to freedom are > naturally alert to repel invasion of their liberty by evil-minded > rulers. The greatest dangers to liberty lurk in insidious encroachment > by men of zeal, well-meaning but without understanding. > --Louis D. Brandeis -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The chance of forgetting something is directly proportional to.....to........uh.............. From nobody Wed Jan 11 00:59:19 2017 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 E8A03127058; Wed, 11 Jan 2017 00:59:14 -0800 (PST) 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.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148412515494.10401.12383878650641883939.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2017 00:59:14 -0800 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-22.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: Wed, 11 Jan 2017 08:59:15 -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-22.txt Pages : 46 Date : 2017-01-11 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 SIP INFO requests. Although this specification is designed to meet the requirements of European next-generation eCall, it is specified generically such that the technology can be re-used or extended to suit requirements across jurisdictions. 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-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-22 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 Wed Jan 11 00:59:34 2017 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 57FE5129AB4; Wed, 11 Jan 2017 00:59:28 -0800 (PST) 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.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148412516834.10360.2079844163829412295.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2017 00:59:28 -0800 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-21.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: Wed, 11 Jan 2017 08:59:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies of the IETF. Title : Next-Generation Vehicle-Initiated Emergency Calls Authors : Randall Gellens Brian Rosen Hannes Tschofenig Filename : draft-ietf-ecrit-car-crash-21.txt Pages : 43 Date : 2017-01-11 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 a SIP INFO package to enable carrying this and related data in SIP 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 use of 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 IETF 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 SIP 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-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 13 01:28:31 2017 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 689C412944F; Fri, 13 Jan 2017 01:28:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148429970538.26834.8601617779578525696.idtracker@ietfa.amsl.com> Date: Fri, 13 Jan 2017 01:28:25 -0800 Archived-At: Cc: draft-ietf-ecrit-car-crash.all@ietf.org, ietf@ietf.org, ecrit@ietf.org Subject: [Ecrit] Review of draft-ietf-ecrit-car-crash-21 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, 13 Jan 2017 09:28:25 -0000 Reviewer: Dan Romascanu Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-ecrit-car-crash-21 Reviewer: Dan Romascanu Review Date: 2017-01-13 IETF LC End Date: 2017-01-06 IESG Telechat date: 2017-01-19 Summary: Ready It's a good and useful document which needs to be read and understood together with the eCall document, and other relevant documents from EC, NENA, APCOT. The IETF Last Call review included a number of comments which were considered and appropriately addressed. Thank you. Major issues: Minor issues: Nits/editorial comments: From nobody Sun Jan 15 03:18:28 2017 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 48BFA12944D; Sun, 15 Jan 2017 03:18:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148447910225.28492.12335006343615469796.idtracker@ietfa.amsl.com> Date: Sun, 15 Jan 2017 03:18:22 -0800 Archived-At: Cc: draft-ietf-ecrit-ecall@ietf.org, allison.mankin@gmail.com, ecrit@ietf.org, ecrit-chairs@ietf.org Subject: [Ecrit] Alexey Melnikov's Discuss on draft-ietf-ecrit-ecall-22: (with DISCUSS and COMMENT) 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, 15 Jan 2017 11:18:22 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-ecrit-ecall-22: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a well written document. I have only a couple of minor issues I would like to discuss before recommending approval: 1) +per media type suffix needs to be registered in 2) In 9.1.1.2: should "details" element allow for language tag XML attribute? Should this element be allowed to appear multiple times with different language tags in order to allow for multiple human readable reasons (in different languages)? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- On page 23, in the example: typo Content-Dispositio From nobody Sun Jan 15 14:13:28 2017 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 4096B129857; Sun, 15 Jan 2017 14:13:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148451840322.3259.8343083066167518487.idtracker@ietfa.amsl.com> Date: Sun, 15 Jan 2017 14:13:23 -0800 Archived-At: Cc: ecrit@ietf.org, allison.mankin@gmail.com, draft-ietf-ecrit-car-crash@ietf.org, ecrit-chairs@ietf.org Subject: [Ecrit] Alexey Melnikov's No Objection on draft-ietf-ecrit-car-crash-21: (with COMMENT) 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, 15 Jan 2017 22:13:23 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-ecrit-car-crash-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In 9.4.1 there are 2 "supported-values" attributes: one contains space after ";" and another one contains multiple CRLF. Does this conform to the syntax in the ecall draft? Similar question about section 11. From nobody Sun Jan 15 21:52:51 2017 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 CDFB81293F4; Sun, 15 Jan 2017 21:52:45 -0800 (PST) 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: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 ngk5NX4zZoKR; Sun, 15 Jan 2017 21:52:44 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 56F2F1293F5; Sun, 15 Jan 2017 21:52:44 -0800 (PST) Received: from [10.188.178.80] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 15 Jan 2017 21:50:02 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <148447910225.28492.12335006343615469796.idtracker@ietfa.amsl.com> References: <148447910225.28492.12335006343615469796.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Sun, 15 Jan 2017 21:52:37 -0800 To: "Alexey Melnikov" , "The IESG" 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: draft-ietf-ecrit-ecall@ietf.org, Allison Mankin , ecrit@ietf.org, ecrit-chairs@ietf.org Subject: Re: [Ecrit] Alexey Melnikov's Discuss on draft-ietf-ecrit-ecall-22: (with DISCUSS and COMMENT) 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, 16 Jan 2017 05:52:46 -0000 Hi Alexey, Thanks for your review and comments. Please see inline. At 3:18 AM -0800 1/15/17, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-ecrit-ecall-22: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is a well written document. I have only a couple of minor issues I > would like to discuss before recommending approval: > > 1) +per media type suffix needs to be registered in > > I added this to the draft. > 2) In 9.1.1.2: should "details" element allow for language tag XML > attribute? Should this element be allowed to appear multiple times with > different language tags in order to allow for multiple human readable > reasons (in different languages)? "Details" is a parameter, not an element, and hence cannot appear multiple times. The intent is for internal use and troubleshooting, not for display to users. I'm not sure there would be enough benefit to change it to an element to permit multiple occurrences and to have a language tag. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > On page 23, in the example: typo Content-Dispositio Fixed, thanks. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Paranoids are the only ones who notice things anymore. --Anatole Broyard From nobody Sun Jan 15 22:00:36 2017 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 909FD129513; Sun, 15 Jan 2017 22:00:34 -0800 (PST) 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: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 B5ir1tu0azNV; Sun, 15 Jan 2017 22:00:33 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5691293F4; Sun, 15 Jan 2017 22:00:30 -0800 (PST) Received: from [10.188.178.80] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 15 Jan 2017 21:57:47 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <148451840322.3259.8343083066167518487.idtracker@ietfa.amsl.com> References: <148451840322.3259.8343083066167518487.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Sun, 15 Jan 2017 22:00:23 -0800 To: "Alexey Melnikov" , "The IESG" 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, Allison Mankin , draft-ietf-ecrit-car-crash@ietf.org, ecrit-chairs@ietf.org Subject: Re: [Ecrit] Alexey Melnikov's No Objection on draft-ietf-ecrit-car-crash-21: (with COMMENT) 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, 16 Jan 2017 06:00:34 -0000 Hi Alexey, Thanks for your review. I added "Multiple values are separated with a semicolon. " to the text definition in the eCall draft to make it clear. --Randy At 2:13 PM -0800 1/15/17, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-ecrit-car-crash-21: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In 9.4.1 there are 2 "supported-values" attributes: one contains space > after ";" and another one contains multiple CRLF. Does this conform to > the syntax in the ecall draft? > > Similar question about section 11. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- It is easier to fight for one's principles than to live up to them. --Alfred Adler From nobody Mon Jan 16 02:12:00 2017 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 C065E129447; Mon, 16 Jan 2017 02:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmail.fm header.b=ZpLjgF44; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=DRvBtzH3 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 v2nB0wYlNunC; Mon, 16 Jan 2017 02:11:57 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9AAD1293E9; Mon, 16 Jan 2017 02:11:57 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 50E412094B; Mon, 16 Jan 2017 05:11:55 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Mon, 16 Jan 2017 05:11:55 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=lTPDWdrt2FTKEG+ q/SeS5BkS8gM=; b=ZpLjgF44aPwqYnwnrhtX1qJgdubJ4z4AZyJR7ph/idY4j1P agmxbWsv8yNcLf0wz7aE9wj0QCtMQw4FetvXokBaSWaeQg/PYrBucfIQLlhk6V3x H2RUUT9HyD5dhIZnLMxFfF1M894nxn4ePEzkLS1Yhvqjqlr/70hDIV4e43ro= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=lTPDWdrt2FTKEG+q/SeS5BkS8gM=; b=DRvBtzH3NERS+vSdsgnR HF/ZN9Tt5JmZ4hWMki+RJohv20FmiKfVlKV45O4YPUXMGFcnR/jX6FCjyREl90JJ zMADbs4LjCKjAR1CEZME3pXrp95LMVwZrPZ2x54KnLXOswDd+8J5A38FKo5KL0rB KzXz6xcpK2jrCnJAmBiwyX4= X-ME-Sender: X-Sasl-enc: UY9G4d8G1ZMQqp5PrPmbN19Td7O/KSj1vnRl6YieW8Ba 1484561514 Received: from [10.238.179.8] (unknown [185.69.145.109]) by mail.messagingengine.com (Postfix) with ESMTPA id ED0622443E; Mon, 16 Jan 2017 05:11:54 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Mon, 16 Jan 2017 10:21:31 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2AD6D672-B34C-4BFC-BA2C-469AC2B9622A@fastmail.fm> References: <148447910225.28492.12335006343615469796.idtracker@ietfa.amsl.com> To: Randall Gellens Archived-At: Cc: draft-ietf-ecrit-ecall@ietf.org, ecrit-chairs@ietf.org, The IESG , ecrit@ietf.org, Allison Mankin Subject: Re: [Ecrit] Alexey Melnikov's Discuss on draft-ietf-ecrit-ecall-22: (with DISCUSS and COMMENT) 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, 16 Jan 2017 10:11:58 -0000 Hi Randy, On 16 Jan 2017, at 05:52, Randall Gellens wrote:= >> 2) In 9.1.1.2: should "details" element allow for language tag XML >> attribute? Should this element be allowed to appear multiple times with >> different language tags in order to allow for multiple human readable >> reasons (in different languages)? >=20 > "Details" is a parameter, not an element, and hence cannot appear multiple= times. The intent is for internal use and troubleshooting, not for display= to users. I'm not sure there would be enough benefit to change it to an el= ement to permit multiple occurrences and to have a language tag. This is good enough for me. You might want to say something like this in the= draft. From nobody Mon Jan 16 05:03:26 2017 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 F18201299E4; Mon, 16 Jan 2017 05:03:24 -0800 (PST) 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: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 Gnjlu4dbesFf; Mon, 16 Jan 2017 05:03:19 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A362C1299E5; Mon, 16 Jan 2017 05:02:47 -0800 (PST) Received: from [10.188.178.80] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 16 Jan 2017 05:00:02 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <2AD6D672-B34C-4BFC-BA2C-469AC2B9622A@fastmail.fm> References: <148447910225.28492.12335006343615469796.idtracker@ietfa.amsl.com> <2AD6D672-B34C-4BFC-BA2C-469AC2B9622A@fastmail.fm> X-Mailer: Eudora for Mac OS X Date: Mon, 16 Jan 2017 05:02:42 -0800 To: Alexey Melnikov , Randall Gellens 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: draft-ietf-ecrit-ecall@ietf.org, ecrit-chairs@ietf.org, The IESG , ecrit@ietf.org, Allison Mankin Subject: Re: [Ecrit] Alexey Melnikov's Discuss on draft-ietf-ecrit-ecall-22: (with DISCUSS and COMMENT) 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, 16 Jan 2017 13:03:25 -0000 At 10:21 AM +0000 1/16/17, Alexey Melnikov wrote: > Hi Randy, > > On 16 Jan 2017, at 05:52, Randall Gellens wrote: > >>> 2) In 9.1.1.2: should "details" element allow for language tag XML >>> attribute? Should this element be allowed to appear multiple times with >>> different language tags in order to allow for multiple human readable >>> reasons (in different languages)? >> > > "Details" is a parameter, not an element, and hence cannot > appear multiple times. The intent is for internal use and > troubleshooting, not for display to users. I'm not sure there > would be enough benefit to change it to an element to permit > multiple occurrences and to have a language tag. > > This is good enough for me. You might want to say something like > this in the draft. Good idea. I added: This is intended for internal use and troubleshooting, not for display to vehicle occupants. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The last good thing written in C was Franz Schubert's Ninth Symphony. From nobody Mon Jan 16 05:21:39 2017 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 CA33D129431; Mon, 16 Jan 2017 05:21:37 -0800 (PST) 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.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148457289782.22600.13606146201516475289.idtracker@ietfa.amsl.com> Date: Mon, 16 Jan 2017 05:21:37 -0800 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-23.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, 16 Jan 2017 13:21:38 -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-23.txt Pages : 48 Date : 2017-01-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 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 SIP INFO requests. Although this specification is designed to meet the requirements of European next-generation eCall, it is specified generically such that the technology can be re-used or extended to suit requirements across jurisdictions. 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-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-23 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 Jan 16 05:24:29 2017 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 A653A12948F; Mon, 16 Jan 2017 05:24:24 -0800 (PST) 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: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 nERr5YWGyxcw; Mon, 16 Jan 2017 05:24:24 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id F117912945D; Mon, 16 Jan 2017 05:24:23 -0800 (PST) Received: from [10.188.178.80] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 16 Jan 2017 05:21:39 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <148447910225.28492.12335006343615469796.idtracker@ietfa.amsl.com> <2AD6D672-B34C-4BFC-BA2C-469AC2B9622A@fastmail.fm> X-Mailer: Eudora for Mac OS X Date: Mon, 16 Jan 2017 05:24:18 -0800 To: Alexey Melnikov 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: draft-ietf-ecrit-ecall@ietf.org, ecrit-chairs@ietf.org, The IESG , ecrit@ietf.org, Allison Mankin Subject: Re: [Ecrit] Alexey Melnikov's Discuss on draft-ietf-ecrit-ecall-22: (with DISCUSS and COMMENT) 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, 16 Jan 2017 13:24:24 -0000 I uploaded revision -23 which has these changes. Thanks again. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- This is a nasty, rotten business. --Robert L. Crandall, CEO & President of American Airlines From nobody Mon Jan 16 06:16:51 2017 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 C8C8E1294E8; Mon, 16 Jan 2017 06:16:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148457620979.22478.2355384427078619260.idtracker@ietfa.amsl.com> Date: Mon, 16 Jan 2017 06:16:49 -0800 Archived-At: Cc: draft-ietf-ecrit-ecall@ietf.org, allison.mankin@gmail.com, ecrit@ietf.org, ecrit-chairs@ietf.org Subject: [Ecrit] Alexey Melnikov's No Objection on draft-ietf-ecrit-ecall-23: (with COMMENT) 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, 16 Jan 2017 14:16:50 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-ecrit-ecall-23: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for quick handling of my DISCUSS points. One nit: in 14.1: Contact: Apps Area Working Group (apps-discuss@ietf.org) This should probably be art@ietf.org From nobody Mon Jan 16 07:16:57 2017 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 8B41F129557; Mon, 16 Jan 2017 07:16:51 -0800 (PST) X-Quarantine-ID: <0TrU9avSgACQ> 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: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 0TrU9avSgACQ; Mon, 16 Jan 2017 07:16:50 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA17129554; Mon, 16 Jan 2017 07:16:50 -0800 (PST) Received: from [10.186.219.182] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 16 Jan 2017 07:14:04 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <148457620979.22478.2355384427078619260.idtracker@ietfa.amsl.com> References: <148457620979.22478.2355384427078619260.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Mon, 16 Jan 2017 07:16:44 -0800 To: "Alexey Melnikov" , "The IESG" 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: draft-ietf-ecrit-ecall@ietf.org, ecrit-chairs@ietf.org, allison.mankin@gmail.com, ecrit@ietf.org Subject: Re: [Ecrit] Alexey Melnikov's No Objection on draft-ietf-ecrit-ecall-23: (with COMMENT) 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, 16 Jan 2017 15:16:51 -0000 At 6:16 AM -0800 1/16/17, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-ecrit-ecall-23: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for quick handling of my DISCUSS points. > > One nit: in 14.1: > > Contact: Apps Area Working Group (apps-discuss@ietf.org) > > This should probably be art@ietf.org Thanks. I fixed this, but will hold off uploading a revision to see if further IESG comments come in. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I was gratified to be able to answer promptly, and I did. I said I didn't know." --Mark Twain From nobody Tue Jan 17 05:05:13 2017 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 02BC11293E1; Tue, 17 Jan 2017 05:05:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148465831000.31986.8406297543964675711.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2017 05:05:10 -0800 Archived-At: Cc: draft-ietf-ecrit-ecall@ietf.org, allison.mankin@gmail.com, ecrit@ietf.org, ecrit-chairs@ietf.org Subject: [Ecrit] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-ecrit-ecall-23=3A_=28with_COMMENT=29?= 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, 17 Jan 2017 13:05:10 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-ecrit-ecall-23: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Minor comments: - sec 9.1.1.1: Is there a case where 'received' could be not 'true'. I mean how can you acknowledge something that you didn't receive? - I find the wording used saying "This document registers .." (in the whole document) not fully approrpiate because the main purpose of this doc is the spcification of the usage of these registrations. I would propose the following, e.g. OLD "This document registers "urn:service:test.sos.ecall" for eCall test calls." NEW "This document specifies "urn:service:test.sos.ecall" for eCall test calls and registers it in section X." From nobody Tue Jan 17 06:00:27 2017 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 8AE8E1293DF; Tue, 17 Jan 2017 06:00:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148466162552.31998.1038836224962937327.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2017 06:00:25 -0800 Archived-At: Cc: ecrit@ietf.org, allison.mankin@gmail.com, draft-ietf-ecrit-car-crash@ietf.org, ecrit-chairs@ietf.org Subject: [Ecrit] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-ecrit-car-crash-21=3A_=28with_COMMENT=29?= 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, 17 Jan 2017 14:00:25 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-ecrit-car-crash-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few comments: - "Migration of the three architectural models to next-generation (all-IP)" could be an own section - Shouldn't this last part of section 6 ("If new data blocks are needed...") go into I-D.ietf-ecrit-ecall? - There is a lot of redunancy within this document but also compared to I-D.ietf-ecrit-ecall (mainly section 8, some parts of 9, and 10). Is there no better way to handle this? - There is no action to unlock door (in section 9). I assume that's because of the security risk of someone unlocking doors remotely. If that's the case I would also remove this from the example list used previously in the doc several times. Maybe instead discuss this case in the security considerations? - Does it really need a Lamp State Registry? What additional states could come up in future beside 'on', 'off', and 'flash'? And even is there are additional states, will that change dynamically enough to have an own registry? From nobody Wed Jan 18 13:55:43 2017 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 9E07A1294E6; Wed, 18 Jan 2017 13:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 YughsgTiIc9w; Wed, 18 Jan 2017 13:55:38 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 54F06129437; Wed, 18 Jan 2017 13:55:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A08032CD02; Wed, 18 Jan 2017 23:55:37 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmfMbns7qxDD; Wed, 18 Jan 2017 23:55:37 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 1E2DE2CCAF; Wed, 18 Jan 2017 23:55:37 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3CD7546D-BC0E-44A6-B805-948A86DEEBBE"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <148429970538.26834.8601617779578525696.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 23:55:35 +0200 Message-Id: <713C4024-75C9-47CE-B98B-08667FFE441B@piuha.net> References: <148429970538.26834.8601617779578525696.idtracker@ietfa.amsl.com> To: Dan Romascanu X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "gen-art@ietf.org Review Team" , draft-ietf-ecrit-car-crash.all@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] Review of draft-ietf-ecrit-car-crash-21 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, 18 Jan 2017 21:55:39 -0000 --Apple-Mail=_3CD7546D-BC0E-44A6-B805-948A86DEEBBE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dan: Many thanks for the review, and thanks to Randall and others for = the edits. I have balloted no-objection for this document on tomorrow=92s IESG = telechat. Jari --Apple-Mail=_3CD7546D-BC0E-44A6-B805-948A86DEEBBE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYf+RXAAoJEM80gCTQU46qRPYP+gKAzL6KBraoR+ZtnKV+bJED RQNSSYGpzHMwhSciSbV5Cv7a0GVQ7enSVr+zX7LQDUBrGTkaYRYAhIsWlHKyMCoL 9c4wqDvNNfKWxRRa/hMHlN1BZUQp9OytCI+5OB9P1pIBn4WvoBXdfFwMvvoGOxdG sjby7WRZFM6e5m+ysO9bmlOixWV25JEZbPc+JIhQh1YjYhawSDo8mSASRwCQVph0 8sVoyyOBDFBtF2a8TzcmjeKISZQlS35x5nd9BWii4Fmz3/i/aFmRngCIBJCentFp stAadr468zx/6nDnoVlM5HoXgK1FpOcDiSyrz/9scX/ulB4P3I/uRsLN6MF1x4w/ 0z2tP7hVh5QNm5WcA/187uuzOR7oYJgec81CBPaCXQRFZaamFvu7aB+GZRFgTsZp munct2kX+3zx/By1Vl3Qt52Jq+P/M4vYVnHoxzCeoN1HnprBGIwr0Nn3h9bB/0qX +l4RU7dBntgSd1UnyZFdRG39HAHbMXlsNdiFEhWRCXPZdgD8jG1jRPbcAvFwKB/C BiZ/uHRB1aybIvqfC29Ub7IIERfYAR+1yBKJLr64TbdbVvy8E1wM3L5bRXrngXjo Zjjoqcmw4ogj7HHHyIauTImDbGAVsqIox8O/x4Mr6LwHzv3oKdEWFAeQhvkeR3Ru UCGBYWsCcrJuICpxEERA =ilss -----END PGP SIGNATURE----- --Apple-Mail=_3CD7546D-BC0E-44A6-B805-948A86DEEBBE-- From nobody Wed Jan 18 18:40:36 2017 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 233A2129453; Wed, 18 Jan 2017 18:40:33 -0800 (PST) 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.05 X-Spam-Level: X-Spam-Status: No, score=-4.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RP_MATCHES_RCVD=-3.199] 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 KL8wOoqNUKIb; Wed, 18 Jan 2017 18:40:18 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1019D127A90; Wed, 18 Jan 2017 18:40:17 -0800 (PST) Received: from [10.186.219.182] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 18 Jan 2017 18:37:05 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <148465831000.31986.8406297543964675711.idtracker@ietfa.amsl.com> References: <148465831000.31986.8406297543964675711.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Wed, 18 Jan 2017 06:20:42 -0800 To: "Mirja Kuehlewind" , "The IESG" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable 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: draft-ietf-ecrit-ecall@ietf.org, Allison Mankin , ecrit@ietf.org, ecrit-chairs@ietf.org Subject: Re: [Ecrit] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on__dra?= =?iso-8859-1?q?ft-ietf-ecrit-ecall-23=3A_=28with_COMMENT=29?= 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, 19 Jan 2017 02:40:33 -0000 Hi Mirja, Thanks for your review. Please see inline. At 5:05 AM -0800 1/17/17, Mirja Kuehlewind wrote: > Mirja K=FChlewind has entered the following ballot position for > draft-ietf-ecrit-ecall-23: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Minor comments: > - sec 9.1.1.1: Is there a case where 'received' could be not 'true'. I > mean how can you acknowledge something that you didn't receive? That section says "this element indicates=20 if the PSAP considers the MSD successfully=20 received or not." Unlike legacy (CS) eCall, the=20 MSD can't get corrupted during transit, but it's=20 possible that there is a bug in either the IVS's=20 creation of the MSD or the PSAP's interpretation=20 of it. > - I find the wording used saying "This document registers .." (in the > whole document) not fully approrpiate because the main purpose of this > doc is the spcification of the usage of these registrations. I would > propose the following, e.g. > OLD > "This document registers "urn:service:test.sos.ecall" for eCall test > calls." > NEW > "This document specifies "urn:service:test.sos.ecall" for eCall test > calls and registers it in section X." I reviewed each use of "registers" in the=20 document; to me, the uses are appropriate and=20 except for the service URNs that you mention,=20 alternative wording would be awkward. I did make=20 the changes you suggest for the service URNs=20 (both "SOS" and "test"). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Did you know that clones never use mirrors? From nobody Thu Jan 19 00:04:23 2017 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 E34C2129458; Thu, 19 Jan 2017 00:04:22 -0800 (PST) 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: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 eV_EsYIPZFlC; Thu, 19 Jan 2017 00:04:21 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 702AF129445; Thu, 19 Jan 2017 00:04:21 -0800 (PST) Received: from [10.186.219.182] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 19 Jan 2017 00:01:06 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <148466162552.31998.1038836224962937327.idtracker@ietfa.amsl.com> References: <148466162552.31998.1038836224962937327.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Thu, 19 Jan 2017 00:00:47 -0800 To: "Mirja Kuehlewind" , "The IESG" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable 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, Allison Mankin , draft-ietf-ecrit-car-crash@ietf.org, ecrit-chairs@ietf.org Subject: Re: [Ecrit] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on__dra?= =?iso-8859-1?q?ft-ietf-ecrit-car-crash-21=3A_=28with_COMMENT=29?= 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, 19 Jan 2017 08:04:23 -0000 Hi Mirja, Thanks for your comments. Please see inline. At 6:00 AM -0800 1/17/17, Mirja Kuehlewind wrote: > Mirja K=FChlewind has entered the following ballot position for > draft-ietf-ecrit-car-crash-21: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > A few comments: > - "Migration of the three architectural models to next-generation > (all-IP)" could be an own section It could be a subsection, but I think it fits well as flow within the sectio= n. > - Shouldn't this last part of section 6 ("If new data blocks are > needed...") go into I-D.ietf-ecrit-ecall? It was originally there, but was moved here=20 because that draft is more focused on eCall,=20 while this draft is the more general extension,=20 so it seems to fit well here. > - There is a lot of redunancy within this document but also compared to > I-D.ietf-ecrit-ecall (mainly section 8, some parts of 9, and 10). Is > there no better way to handle this? I rewrote several sections of both drafts to=20 remove unnecessary redundancy to dress Alissa's=20 review comments prior to IESG submission. If=20 there are additional edits you feel would enhance=20 the readability, please let me know the specifics. > - There is no action to unlock door (in section 9). I assume that's > because of the security risk of someone unlocking doors remotely. If > that's the case I would also remove this from the example list used > previously in the doc several times. Maybe instead discuss this case in > the security considerations? Thanks for catching this, I appreciate it. This=20 was an error that was introduced when the=20 specific actions not needed for eCall were moved=20 into this draft and made more general. I've=20 fixed it by readding the "door-lock" action and=20 the text explaining that the "requested-state"=20 attribute is set to "locked" or "unlocked". > - Does it really need a Lamp State Registry? What additional states could > come up in future beside 'on', 'off', and 'flash'? And even is there are > additional states, will that change dynamically enough to have an own > registry? Well, it's already been suggested that changing=20 color might be added, but I agree that we=20 probably don't need the registry. I'll specify=20 the three values now. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad. --James Madison, 4th US president (1751-1836) From nobody Thu Jan 19 02:27:12 2017 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 4B44E126BF7; Thu, 19 Jan 2017 02:27:10 -0800 (PST) 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.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148482163030.10353.4745057676400172075.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 02:27:10 -0800 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-24.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: Thu, 19 Jan 2017 10:27:10 -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-24.txt Pages : 48 Date : 2017-01-19 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 SIP INFO requests. Although this specification is designed to meet the requirements of European next-generation eCall, it is specified generically such that the technology can be re-used or extended to suit requirements across jurisdictions. 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-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-24 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 Thu Jan 19 02:27:45 2017 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 95410126BF7; Thu, 19 Jan 2017 02:27:44 -0800 (PST) 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.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148482166460.10377.1340523715253770726.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 02:27:44 -0800 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-22.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: Thu, 19 Jan 2017 10:27:44 -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-22.txt Pages : 42 Date : 2017-01-19 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 a SIP INFO package to enable carrying this and related data in SIP 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 use of 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 IETF 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 SIP 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-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-22 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 Thu Jan 19 06:51:25 2017 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 EFB9412941A; Thu, 19 Jan 2017 06:51:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148483747797.10305.8523660705109689253.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 06:51:17 -0800 Archived-At: Cc: ecrit@ietf.org, allison.mankin@gmail.com, draft-ietf-ecrit-car-crash@ietf.org, ecrit-chairs@ietf.org Subject: [Ecrit] Stephen Farrell's No Objection on draft-ietf-ecrit-car-crash-22: (with COMMENT) 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: Thu, 19 Jan 2017 14:51:20 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-ecrit-car-crash-22: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A phone call that can unlock the doors and turn on an in-car camera. What could possibly go wrong? I think the security considerations ought warn more specifically about the consequences of these options. This is not a discuss as I assume that these features are required by US regulators, and so cannot be removed. If they were under IETF control, I'd want to DISCUSS removing them entirely as I suspect that the overall cost/benefit of these features would imply we'd be better off without them. From nobody Thu Jan 19 07:33:55 2017 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 EABF5129487 for ; Thu, 19 Jan 2017 07:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 yrpStbKoF2UC for ; Thu, 19 Jan 2017 07:33:53 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62F412896F for ; Thu, 19 Jan 2017 07:33:52 -0800 (PST) Received: (qmail 16315 invoked from network); 19 Jan 2017 16:27:09 +0100 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 19 Jan 2017 16:27:09 +0100 To: Randall Gellens , The IESG References: <148466162552.31998.1038836224962937327.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: Date: Thu, 19 Jan 2017 16:27:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ecrit@ietf.org, Allison Mankin , draft-ietf-ecrit-car-crash@ietf.org, ecrit-chairs@ietf.org Subject: Re: [Ecrit] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-ecrit-car-crash-21=3A_=28with_COMMENT=29?= 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, 19 Jan 2017 15:33:54 -0000 Hi Randall, please see below. On 19.01.2017 09:00, Randall Gellens wrote: > Hi Mirja, > > Thanks for your comments. Please see inline. > > At 6:00 AM -0800 1/17/17, Mirja Kuehlewind wrote: > >> Mirja Kühlewind has entered the following ballot position for >> draft-ietf-ecrit-car-crash-21: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> A few comments: >> - "Migration of the three architectural models to next-generation >> (all-IP)" could be an own section > > It could be a subsection, but I think it fits well as flow within the section. > >> - Shouldn't this last part of section 6 ("If new data blocks are >> needed...") go into I-D.ietf-ecrit-ecall? > > It was originally there, but was moved here > because that draft is more focused on eCall, > while this draft is the more general extension, > so it seems to fit well here. Okay. The split of this being more general wasn't clear to me because this one is referencing the other one, while the other does not refer this one... > >> - There is a lot of redunancy within this document but also compared to >> I-D.ietf-ecrit-ecall (mainly section 8, some parts of 9, and 10). Is >> there no better way to handle this? > > I rewrote several sections of both drafts to > remove unnecessary redundancy to dress Alissa's > review comments prior to IESG submission. If > there are additional edits you feel would enhance > the readability, please let me know the specifics. I read both doc after each other and just has a dejavue in sec 8, 9, and 10. But probably you might not read both at once usually... I don't have concrete proposals (sorry don't have time...) > >> - There is no action to unlock door (in section 9). I assume that's >> because of the security risk of someone unlocking doors remotely. If >> that's the case I would also remove this from the example list used >> previously in the doc several times. Maybe instead discuss this case in >> the security considerations? > > Thanks for catching this, I appreciate it. This > was an error that was introduced when the > specific actions not needed for eCall were moved > into this draft and made more general. I've > fixed it by readding the "door-lock" action and > the text explaining that the "requested-state" > attribute is set to "locked" or "unlocked". Okay, in this case I would also like to see some discussion in the security section! > >> - Does it really need a Lamp State Registry? What additional states could >> come up in future beside 'on', 'off', and 'flash'? And even is there are >> additional states, will that change dynamically enough to have an own >> registry? > > Well, it's already been suggested that changing > color might be added, but I agree that we > probably don't need the registry. I'll specify > the three values now. > Okay! Thanks! Mirja From nobody Thu Jan 19 19:16:03 2017 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 428F6129721; Thu, 19 Jan 2017 19:16:02 -0800 (PST) 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: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 xukwVND9x2L1; Thu, 19 Jan 2017 19:16:01 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDA912952D; Thu, 19 Jan 2017 19:16:01 -0800 (PST) Received: from [10.187.125.193] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 19 Jan 2017 19:12:37 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <148483747797.10305.8523660705109689253.idtracker@ietfa.amsl.com> References: <148483747797.10305.8523660705109689253.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Thu, 19 Jan 2017 19:15:55 -0800 To: "Stephen Farrell" , "The IESG" 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-chairs@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-car-crash@ietf.org, allison.mankin@gmail.com Subject: Re: [Ecrit] Stephen Farrell's No Objection on draft-ietf-ecrit-car-crash-22: (with COMMENT) 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, 20 Jan 2017 03:16:02 -0000 Hi Stephen, I added additional text to the Security Considerations pointing out that some actions are riskier than others, and reiterating that vehicles can decline requests for whatever reason, and mentioning some potential policy choices. Note that the existing text already pointed out that vehicles could refuse a request if it wasn't signed by an acceptable emergency services certificate. At 6:51 AM -0800 1/19/17, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-ecrit-car-crash-22: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > A phone call that can unlock the doors and turn on an in-car > camera. What could possibly go wrong? I think the security > considerations ought warn more specifically about the > consequences of these options. This is not a discuss as I > assume that these features are required by US regulators, and > so cannot be removed. If they were under IETF control, I'd > want to DISCUSS removing them entirely as I suspect that the > overall cost/benefit of these features would imply we'd be > better off without them. > > > _______________________________________________ > 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 only normal people are the ones you don't know very well. --Joe Ancis From nobody Thu Jan 19 19:17:13 2017 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 44EFA129721; Thu, 19 Jan 2017 19:17:11 -0800 (PST) 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.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148488223124.10653.15936571945352132357.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 19:17:11 -0800 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-23.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, 20 Jan 2017 03:17:11 -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-23.txt Pages : 42 Date : 2017-01-19 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 a SIP INFO package to enable carrying this and related data in SIP 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 use of 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 IETF 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 SIP 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-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-23 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 Jan 31 03:48:51 2017 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 854F0129E19 for ; Tue, 31 Jan 2017 03:48:49 -0800 (PST) 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 QxZ-z_EoOzj1 for ; Tue, 31 Jan 2017 03:48:47 -0800 (PST) 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 67164129E15 for ; Tue, 31 Jan 2017 03:48:47 -0800 (PST) X-AuditID: c1b4fb2d-a87ff70000007e3d-48-5890799ce213 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 99.E0.32317.C9970985; Tue, 31 Jan 2017 12:48:45 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0319.002; Tue, 31 Jan 2017 12:48:44 +0100 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-content-id-00 Thread-Index: AQHSe7f5DZbsDe83KUqY7fblEw9OJQ== Date: Tue, 31 Jan 2017 11:48:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2K7ve7cygkRBttuGFo0LnrK6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIXXJ7MX7OWoeP72BVsD4zu2LkZODgkBE4kHzR/Zuxi5OIQE 1jFKbNu7BMpZzCjx4sd0li5GDg42AQuJ7n/aIA0iAqoSG86sZASxhQW8JK6/WcsGEfeW2DZj GSuErScx8fdVdhCbBah+17H3YDW8AtYS8zoegNmMAmIS30+tYQKxmQXEJW49mc8EcZCAxJI9 55khbFGJl4//gc0UBZq5/PkaqLiixM6z7cwQvToSC3Z/YoOwrSUWbJ7DDmFrSyxb+JoZYq+g xMmZT1gmMIrMQrJuFpL2WUjaZyFpn4WkfQEj6ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2M wJg4uOW37g7G1a8dDzEKcDAq8fAa9PZHCLEmlhVX5h5ilOBgVhLh1SyZECHEm5JYWZValB9f VJqTWnyIUZqDRUmc12zl/XAhgfTEktTs1NSC1CKYLBMHp1QDI492u/kEl5sfxM6LFqV8ZTLc PKW2frX/SkaOWccSN9gUV6+I+eEmUztx5cJ+F29rtsfPrJhYNy6b5DHF9+fd7TOueAtmT/H4 efK789Lll9Y/nNZzwzd9VkzSD+YbW3aJ+J063PPZesqqd7b71mg4Tdl5oPDR5cURFkxvTr6/ fGdhjLAEs07FNQElluKMREMt5qLiRABjkVGvhQIAAA== Archived-At: Subject: [Ecrit] FW: [sipcore] Draft new version: draft-ietf-sipcore-content-id-00 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, 31 Jan 2017 11:48:49 -0000 FYI, The content-id draft has now been adopted by SIPCORE. If you have interest in the draft, please join the SIPCORE list. Thanks! Regards, Christer On 31/01/17 00:39, "sipcore on behalf of Christer Holmberg" wrote: >Hi, > >We've submitted the initial version of draft-ietf-sipcore-content-id. > >The draft is the outcome of discussions that took place in ECRIT, where >it was realized that the Content-ID header field had not been defined as >a SIP header field (it was only defined as a MIME body header field). The >draft defines it as a SIP header field. > >There are currently no open issues in the draft, and currently I see no >need to reserve agenda time in Chicago. > >But, we ask the community to take a look, to see whether there are some >issues that require f2f discussions. > >Thanks! > >Regards, > >Christer > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore