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

Randall Gellens <rg+ietf@randy.pensive.org> Thu, 15 December 2016 18:17 UTC

Return-Path: <rg+ietf@randy.pensive.org>
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 C95C1129957 for <ecrit@ietfa.amsl.com>; Thu, 15 Dec 2016 10:17:54 -0800 (PST)
X-Quarantine-ID: <FLoy6leMPxzB>
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.796
X-Spam-Level:
X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] 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 FLoy6leMPxzB for <ecrit@ietfa.amsl.com>; Thu, 15 Dec 2016 10:17:53 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 59263129443 for <ecrit@ietf.org>; Thu, 15 Dec 2016 10:17:53 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 15 Dec 2016 10:17:52 -0800
Mime-Version: 1.0
Message-Id: <p06240603d478883777e3@[99.111.97.136]>
In-Reply-To: <603CCA00-6905-4BED-B3B9-CF56086D6DC9@cooperw.in>
References: <97277796-68FC-4967-85B0-3EAE9173DC93@cooperw.in> <p06240607d477882372e1@[99.111.97.136]> <603CCA00-6905-4BED-B3B9-CF56086D6DC9@cooperw.in>
X-Mailer: Eudora for Mac OS X
Date: Thu, 15 Dec 2016 10:17:50 -0800
To: Alissa Cooper <alissa@cooperw.in>
From: Randall Gellens <rg+ietf@randy.pensive.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/KaPfmItlcOOSAZLFGaxmrU28Mhw>
Cc: Emergency Context Resolution with Internet Technologies Discussion List <ecrit@ietf.org>
Subject: Re: [Ecrit] AD evaluation: draft-ietf-ecrit-ecall-20
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2016 18:17:54 -0000

At 9:50 AM -0500 12/15/16, Alissa Cooper wrote:

>   >> = Section 9.1.3.1 =
>>>
>>>  (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.

OK, I changed the name to "int-id" to make it more generic.


>   >> (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)?

This was an error in the car-crash draft, where the old names were 
used.  I've fixed the draft to now correctly use element-id and 
requested-state (and also int-id).

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Violence is the last refuge of the incompetent.
    --Salvador Hardin