Re: [Ecrit] AD evaluation: draft-ietf-ecrit-ecall-20

Alissa Cooper <> Thu, 15 December 2016 14:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A1D31295BE for <>; Thu, 15 Dec 2016 06:50:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=CPKeGZbh; dkim=pass (1024-bit key) header.b=VAdeXec8
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RePXREK4Wy2D for <>; Thu, 15 Dec 2016 06:50:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6BCE51296A3 for <>; Thu, 15 Dec 2016 06:50:39 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id C835E20878; Thu, 15 Dec 2016 09:50:38 -0500 (EST)
Received: from frontend1 ([]) by compute7.internal (MEProxy); Thu, 15 Dec 2016 09:50:38 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; 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=WkHFwIrYC3pwRHn teyym2WtUpQg=; b=CPKeGZbhycyNul0UA8RPuowGz7RRbZ/AOQmQu82s7JDVOrC p+hj9v4QN3jUkuS0/FgYcerVIvklvEDNL8XV3UeY9MbJ82vKU/xQ6VzA96YPUBVD FwQyKrOrR0gxAGq268KOP/mieL4O0SEM6Cowzcp70Un4eLLYwV+E0NmQ70eI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; 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=WkHFwIrYC3pwRHnteyym2WtUpQg=; b=VAdeXec8znOdCHAw+zBY 29Z7IFtpAgOj+WIU+VZ+Tjb8zWo79nVr8gJPWLVJymkfygoALfYg/pAH88Q+u8a1 wlH0N2Sn143Yw57AtERVGPTzf1RdRt3+tF8x1xxnzK94kmYx3ckWA37iakVngH+A XSEJbJbQMJecLOCEzvWvS4s=
X-ME-Sender: <xms:vq1SWKGKikHISMrlGnA13A4m0aHmAfT9pOeiLT8mC-mYiGssMQqhUA>
X-Sasl-enc: emq1wJmZoGKdbd42oAeGOruE/fjyUiiuxNGLXjdQ7mot 1481813438
Received: from (unknown []) by (Postfix) with ESMTPA id 298167E2B2; Thu, 15 Dec 2016 09:50:38 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <>
In-Reply-To: <p06240607d477882372e1@[]>
Date: Thu, 15 Dec 2016 09:50:37 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <p06240607d477882372e1@[]>
To: Randall Gellens <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: Emergency Context Resolution with Internet Technologies Discussion List <>
Subject: Re: [Ecrit] AD evaluation: draft-ietf-ecrit-ecall-20
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, 15 Dec 2016 14:50:41 -0000

Thanks Randy. Trimming down to ones where I have follow-up:

> On Dec 14, 2016, at 6:52 PM, Randall Gellens <> wrote:
>> = Section =
>> (1) msgid is underspecified. What is it supposed to be used for? 
>> Why is it Conditional?
> It's used in draft-ietf-ecrit-car-crash.  It's Conditional because it 
> is only needed when using static messages.  It's used to indicate 
> either the static message that the vehicle should display/speak to 
> the occupants, or the set of static messages supported by the vehicle 
> (by specifying the highest supported value).  I added clarifying text 
> to the Description:
>    Description:  Defined for extensibility.  Documents that make use of
>       it are expected to explain when it is required and how it it used.
> Anything more explicit would require that I mention static messages, 
> which are not used in this document (they're used in car-crash), and 
> I'm afraid that would be more confusing.

The design of this seems like it could be improved, then. Since the attributes are generic and could be used to describe a variety of requests, wouldn’t it make more sense to specify a generic ID attribute in the event that a future extension defines some other action which also makes use of integer IDs? Come to think of it, isn’t this basically what element-ID is for, except that element-ID is a token rather than an integer? If the msgid attribute really only makes sense in the context of a specific extension defined elsewhere, it doesn’t make sense to define it narrowly here.

>> (2) For supported-values, requested-state, and element-ID, what is 
>> the expectation about where and how the permitted values will be 
>> specified?
> Since these are all defined for extensibility, the expectation is 
> that the document that uses it defines this.  The car-crash draft 
> makes use of them and defines this.

I don’t see where car-crash uses requested-state or element-ID. Are you sure you need them (with a caveat about needing some kind of ID, per my comment above)?