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
- [Ecrit] AD evaluation: draft-ietf-ecrit-ecall-20 Alissa Cooper
- Re: [Ecrit] AD evaluation: draft-ietf-ecrit-ecall… Randall Gellens
- Re: [Ecrit] AD evaluation: draft-ietf-ecrit-ecall… Ivo Sedlacek
- Re: [Ecrit] AD evaluation: draft-ietf-ecrit-ecall… Alissa Cooper
- Re: [Ecrit] AD evaluation: draft-ietf-ecrit-ecall… Randall Gellens