Next-Generation Vehicle-Initiated Emergency Calls
draft-ietf-ecrit-car-crash-23
Yes
(Ben Campbell)
No Objection
(Alia Atlas)
(Alvaro Retana)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 21 and is now closed.
Alissa Cooper Former IESG member
(was Discuss, Yes)
Yes
Yes
(2017-02-07)
Unknown
Experts have completed their reviews.
Ben Campbell Former IESG member
Yes
Yes
(for -21)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(2017-01-15 for -21)
Unknown
In 9.4.1 there are 2 "supported-values" attributes: one contains space after ";" and another one contains multiple CRLF. Does this conform to the syntax in the ecall draft? Similar question about section 11.
Alia Atlas Former IESG member
No Objection
No Objection
(for -21)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -21)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -21)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -21)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -22)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -21)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2017-01-17 for -21)
Unknown
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?
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -21)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2017-01-19 for -22)
Unknown
A phone call that can unlock the doors and turn on an in-car camera. What could possibly go wrong? I think the security considerations ought warn more specifically about the consequences of these options. This is not a discuss as I assume that these features are required by US regulators, and so cannot be removed. If they were under IETF control, I'd want to DISCUSS removing them entirely as I suspect that the overall cost/benefit of these features would imply we'd be better off without them.
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -21)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -21)
Unknown