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

From: "Mirja Kuehlewind" <[email-masked]>
Date: Tue, 17 Jan 2017 06:00:25 -0800

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: Randall Gellens <[email-masked]>
Date: Thu, 19 Jan 2017 00:00:47 -0800

Hi Mirja,

Thanks for your comments.  Please see inline.

>  https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/

It could be a subsection, but I think it fits well as flow within the section.

>  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.

>  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.

>  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".

>  additional states, will that change dynamically enough to have an own

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.

-- 
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: Mirja Kühlewind <[email-masked]>
Date: Thu, 19 Jan 2017 16:27:08 +0100

Hi Randall,

please see below.

> 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...

> 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...)

> attribute is set to "locked" or "unlocked".

Okay, in this case I would also like to see some discussion in the security 
section!

> probably don't need the registry.  I'll specify

Okay!

Thanks!
Mirja