Re: [Ecrit] Mirja Kühlewind's No Objection on draft-ietf-ecrit-car-crash-21: (with COMMENT)

Mirja Kühlewind <ietf@kuehlewind.net> Thu, 19 January 2017 15:33 UTC

Return-Path: <ietf@kuehlewind.net>
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 <ecrit@ietfa.amsl.com>; 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 <ecrit@ietfa.amsl.com>; 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 <ecrit@ietf.org>; 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 <rg+ietf@randy.pensive.org>, The IESG <iesg@ietf.org>
References: <148466162552.31998.1038836224962937327.idtracker@ietfa.amsl.com> <p06240608d4a6046e2ccc@[10.186.219.182]>
From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= <ietf@kuehlewind.net>
Message-ID: <a921afad-4022-258e-f31c-7d831a45fa8f@kuehlewind.net>
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: <p06240608d4a6046e2ccc@[10.186.219.182]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/YzLDuBymngpq7eic1N1HbAhUiZs>
Cc: ecrit@ietf.org, Allison Mankin <allison.mankin@gmail.com>, 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: <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, 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