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

[Randall Gellens <[e-mail]>]

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

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

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


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


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

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.

>
>  = Section 15.1 =
>
>  A description needs to be provided for the registration of 
> 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.

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

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.

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

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.

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

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

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

Thanks.

>
>  = Section 5 =
>
>  I think it would help to explain why support for the XML encoding 
> 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]".


>
>  = Section 8 =
>
>  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 =
>
>  s/persistance/persistence/

Oops, thank you for catching this.

>
>  = Section 14 =
>
>  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.


>
>  = Section 15.2 and 15.3 =
>
>  "Sections 7 and Section 8 of [RFC7852] contain more discussion."
>
>  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.