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

From: Alissa Cooper <[email-masked]>
Date: Tue, 6 Dec 2016 05:31:52 -0500

I have reviewed this document in preparation for IETF last call. There are a few items that require discussion before proceeding to LC. I’ve also included nits that should be resolved together with LC comments or beforehand.

Substantive comments requiring attention before issuing IETF:

= Section 5 =

(1) Since the CEN specifications are not publicly available without paying a fee (as far as I could tell), it would help to provide an overview of what fields are included in the MSD. Otherwise it is difficult to do a complete security/privacy analysis of what is being specified in this document.

= Section 9.1.3.1 =

(1) msgid is underspecified. What is it supposed to be used for? Why is it Conditional?

(2) For supported-values, requested-state, and element-ID, what is the expectation about where and how the permitted values will be specified?

= Section 10 =

I think this section should actually be a subsection of Section 15. IANA needs to register this INFO package and therefore the registration needs to be in the IANA considerations section. Also, documents don't typically reference themselves unless the text is part of an IANA registration.

= Section 12 =

The paragraph that begins "Data received from external sources inherently carries implementation risks ..." seems generic and not specific in any way to this specification. Could you elaborate on the specific threats introduced by this specification and specific guidance to mitigate those threats?

= Section 15 =

"This document formalizes the "EmergencyCallData" media (MIME) subtype
   tree.  This tree is used only for content associated with emergency
   communications.  New subtypes in this tree can be registered by the
   IETF or by other standards organizations working with emergency
   communications, using the "Specification Required" rule, which
   implies expert review.  The designated expert is the ECRIT working
   group."

I reviewed the thread on the media-types list, and I think this text is unclear and needs some fixes:

(1) Instead of saying this "formalizes" the tree, I think the text needs to be explicit that it is registering a new subtree rooted at application/EmergencyCallData.

(2) If you intend for the rules for this subtree to mirror the rules for the standards tree specified in RFC 6838, albeit limiting registrants to emergency-services-related SDOs, then the language used there to describe the registration procedures should be copied.

(3) I think the procedure of specifying the WG as the designated expert is not the most effective choice. It introduces an extra round of triage to find a reviewer when a request comes in, and relies on the perpetual existence of the WG. It's fine if you want the IESG to designate multiple experts or even setup a list with a pool of experts to serve as DEs (neither of which need to be specified in the document), but either of those would be preferable to designating the WG as the expert.

= Section 15.1 =

A description needs to be provided for the registration of urn:service:test.sos.ecall.

= Section 15.2 =

"In general, it is acceptable for the data to be unprotected while briefly in
      transit within the Mobile Network Operator (MNO); the MNO is
      trusted to not permit the data to be accessed by third parties."

This does not seem consistent with Sections 9 and 10 of RFC 7852, where TLS is listed as a SHOULD-level requirement due to legacy deployed bases and the priority for calls to be completed in emergency situations, not because of any sort of trust relationship. I think this text needs to be revised to be consistent with RFC 7852.

= Sections 15.4 and 15.5 =

I think you mean Emergency Call Data Types registry as opposed to Emergency Call Data Blocks registry (the latter does not exist). Also note that the Data Types registry has a 'Data About' column that needs to be filled in for these two entries.

I would also recommend fixing all the other references in the document to the Emergency Call Data Blocks registry.

= Section 19 =

Why are EN_16072 and TS22.101 listed as normative, but TS24.229 is listed as informative? I suspect they could all be informative, although I do not have access to EN_16072.

Nits that can be resolved in the next rev (preferably) or together with IETF LC comments:

= Abstract and Section 2 =

Since the IETF defines standards for the big-I Internet, I think it would help to make a clarification similar to the following in the abstract and in Section 2:

"Although this specification is designed to meet the requirements of European next-generation eCall, it is specified generically such that the technology may be re-used or extended to suit requirements across jurisdictions (see, e.g., draft-ietf-ecrit-car-crash)."

Section 2 doesn't quite say this but I think it's important enough to note specifically there and in the abstract.

= Section 3 = 

s/(both of which are registered in Section 15)/(both of which are registered in Section 15)./

= Section 5 =

I think it would help to explain why support for the XML encoding of MSD is not being specified here.

= Section 8 =

You need to explain what CS-eCall is and expand the acronym on first use.

= Section 9.1.1.2 =

The reason codes should be defined and explained here in the body of the document and references from the IANA considerations section, not defined for the first time there.

= Section 9.1.3.1 =

s/persistance/persistence/

= Section 14 =

s/@success='false"/@success="false"/

= Section 15 =

I don't understand why the intro to this section contains the media type subtree registration, rather than having that in its own subsection like all the other subsections of Section 15.

= Section 15.2 and 15.3 =

"Sections 7 and Section 8 of [RFC7852] contain more discussion."

I think you mean Sections 9 and 10.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 14 Dec 2016 15:52:07 -0800

Hi Alissa,

Thank you for your review.  Please see in-line.

At 5:31 AM -0500 12/6/16, Alissa Cooper wrote:

>  I have reviewed this document in preparation for IETF last call. 
> There are a few items that require discussion before proceeding to 
> LC. I've also included nits that should be resolved together with 
> LC comments or beforehand.
>
>  (1) Since the CEN specifications are not publicly available without 
> paying a fee (as far as I could tell), it would help to provide an 
> overview of what fields are included in the MSD. Otherwise it is 
> difficult to do a complete security/privacy analysis of what is 
> being specified in this document.

I added a parenthetical list of the important fields (meaning those 
potentially privacy sensitive):

    Pan-European eCall provides a standardized and mandated set of
    vehicle related data (including VIN, vehicle type, propulsion type,
    current and optionally previous location coordinates, and number of
    occupants), known as the Minimum Set of Data (MSD).

>  (1) msgid is underspecified. What is it supposed to be used for? 

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.

>
>  (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 added the following sentence 
to the Description of all three:

       Documents that make use of it are expected to explain
       when it is is required, the permitted values, and how it it used.

>
>  = Section 10 =
>
>  I think this section should actually be a subsection of Section 15. 
> IANA needs to register this INFO package and therefore the 
> registration needs to be in the IANA considerations section. Also, 
> documents don't typically reference themselves unless the text is 
> part of an IANA registration.

Christer asked it to be made its own section.  I now moved it to be a 
sub-section of the IANA Considerations section.

>
>  = Section 12 =
>
>  The paragraph that begins "Data received from external sources 
> inherently carries implementation risks ..." seems generic and not 
> specific in any way to this specification. Could you elaborate on 
> the specific threats introduced by this specification and specific 
> guidance to mitigate those threats?

It is a pretty generic paragraph.  I now added "including the MSD and 
metadata/control objects" to tie it in to what's new in the document, 
but I agree with you that none of this really needs to be said.  It 
was added by request of an early reviewer who felt it important to 
point out this out, and I figured it wouldn't hurt.

>  (1) Instead of saying this "formalizes" the tree, I think the text 
> needs to be explicit that it is registering a new subtree rooted at 
> application/EmergencyCallData.

I added that and also listed the subtypes that are contained in the 
subtree (the four created in RFC 7852 and the two in this document).

>
>  (2) If you intend for the rules for this subtree to mirror the 
> rules for the standards tree specified in RFC 6838, albeit limiting 
> registrants to emergency-services-related SDOs, then the language 
> used there to describe the registration procedures should be copied.

Rather than copy the wording, I referenced it:

    New subtypes in this subtree follow
    the rules specified in Section 3.1 of [RFC6838], with the additional
    restriction that the standards-related organization MUST be
    responsible for some aspect of emergency communications.

>
>  (3) I think the procedure of specifying the WG as the designated 
> expert is not the most effective choice. It introduces an extra 
> round of triage to find a reviewer when a request comes in, and 
> relies on the perpetual existence of the WG. It's fine if you want 
> the IESG to designate multiple experts or even setup a list with a 
> pool of experts to serve as DEs (neither of which need to be 
> specified in the document), but either of those would be preferable 
> to designating the WG as the expert.

With the new wording that references RFC 6838, the document no longer 
names an expert.

> urn:service:test.sos.ecall.

I added:

    This service requests
    resources associated with a test (non-emergency) call placed by an
    in-vehicle system.  See Section 8 for more information on the test
    eCall request URN.

>  This does not seem consistent with Sections 9 and 10 of RFC 7852, 
> where TLS is listed as a SHOULD-level requirement due to legacy 
> deployed bases and the priority for calls to be completed in 
> emergency situations, not because of any sort of trust 
> relationship. I think this text needs to be revised to be 
> consistent with RFC 7852.

The text is specifically talking about data within the MNO, not data 
in transit between the MNO and the vehicle, or the MNO and the PSAP, 
hence it is entirely consistent with TLS (since when TLS is used, the 
data is in the clear within the entity that received it, as TLS is 
hop-by-hop rather than end-to-end).  However, on review the text does 
not seem needed and so I delete the text you quoted.

>  I think you mean Emergency Call Data Types registry as opposed to 
> Emergency Call Data Blocks registry (the latter does not exist). 
> Also note that the Data Types registry has a 'Data About' column 
> that needs to be filled in for these two entries.
>
>  I would also recommend fixing all the other references in the 
> document to the Emergency Call Data Blocks registry.

That was an old name for the registry.  Thanks for catching this.  I 
fixed all references.

>
>  = Section 19 =
>
>  Why are EN_16072 and TS22.101 listed as normative, but TS24.229 is 
> listed as informative? I suspect they could all be informative, 
> although I do not have access to EN_16072.

I agree, those are now informative references.

>  Since the IETF defines standards for the big-I Internet, I think it 
> would help to make a clarification similar to the following in the 
> abstract and in Section 2:
>
>  "Although this specification is designed to meet the requirements 
> of European next-generation eCall, it is specified generically such 
> that the technology may be re-used or extended to suit requirements 
> across jurisdictions (see, e.g., draft-ietf-ecrit-car-crash)."
>
>  Section 2 doesn't quite say this but I think it's important enough 
> to note specifically there and in the abstract.

I like your wording better than what's in Section 2 now, so I 
replaced that with yours (except with "can" instead of "may" because 
otherwise someone will say it is ambiguous):

    Although this specification is designed to meet the requirements of
    pan-European next-generation eCall, it is specified generically such
    that the technology can be re-used or extended to suit requirements
    across jurisdictions (see, e.g., [I-D.ietf-ecrit-car-crash]), and
    extension points are provided to facilitate this.

I added the same to the Abstract except without the reference to 
car-crash (since references are frowned upon in Abstracts).

> registered in Section 15)./

Thanks.

> of MSD is not being specified here.

It's because 3GPP didn't want it, they insisted on ASN.1.  I added 
"per 3GPP [SDO-3GPP]".

>  You need to explain what CS-eCall is and expand the acronym on first use.

There were only two uses, so I just expanded them both.

>
>  = Section 9.1.1.2 =
>
>  The reason codes should be defined and explained here in the body 
> of the document and references from the IANA considerations 
> section, not defined for the first time there.
>
>  = Section 9.1.3.1 =
>

Oops, thank you for catching this.

>  s/@success='false"/@success="false"/

Good catch, thank you.

>
>  = Section 15 =
>
>  I don't understand why the intro to this section contains the media 
> type subtree registration, rather than having that in its own 
> subsection like all the other subsections of Section 15.

OK, I made it a subsection.

>  I think you mean Sections 9 and 10.

Thanks for catching this.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Day of inquiry.  You will be subpoenaed.

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 15 Dec 2016 13:12:27 +0000

Hello,

Can you please share the up-to-date version of the draft? Thank you.

Kind regards

Ivo Sedlacek

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Randall Gellens
Sent: Thursday, December 15, 2016 12:52 AM
To: Alissa Cooper <[email-masked]>; Emergency Context Resolution with Internet Technologies Discussion List <[email-masked]>
Subject: Re: [Ecrit] AD evaluation: draft-ietf-ecrit-ecall-20

Hi Alissa,

At 5:31 AM -0500 12/6/16, Alissa Cooper wrote:

> There are a few items that require discussion before proceeding to LC. 
> I've also included nits that should be resolved together with LC 
> comments or beforehand.
>
> difficult to do a complete security/privacy analysis of what is being 
> specified in this document.

I added a parenthetical list of the important fields (meaning those potentially privacy sensitive):

>  (1) msgid is underspecified. What is it supposed to be used for? 

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:

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 expectation about where and how the permitted values will be 

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 added the following sentence to the Description of all three:

> documents don't typically reference themselves unless the text is part 
> of an IANA registration.

Christer asked it to be made its own section.  I now moved it to be a sub-section of the IANA Considerations section.

I added:

    This service requests

Thanks.

Good catch, thank you.

-------------- Randomly selected tag: ---------------

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 15 Dec 2016 09:50:37 -0500

Thanks Randy. Trimming down to ones where I have follow-up:

> On Dec 14, 2016, at 6:52 PM, Randall Gellens <[email-masked]> wrote:
> 
>> 
>> = Section 9.1.3.1 =
>> 

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.

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

Thanks,
Alissa

---

From: Randall Gellens <[email-masked]>
Date: Thu, 15 Dec 2016 10:17:50 -0800

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

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

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

-------------- Randomly selected tag: ---------------
Violence is the last refuge of the incompetent.
    --Salvador Hardin