Re: [Ecrit] AD review: draft-ietf-ecrit-additional-data-29

Randall Gellens <randy@qti.qualcomm.com> Wed, 01 July 2015 13:41 UTC

Return-Path: <randy@qti.qualcomm.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42691A8854 for <ecrit@ietfa.amsl.com>; Wed, 1 Jul 2015 06:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.102
X-Spam-Level:
X-Spam-Status: No, score=-5.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 SIFSZRjekekm for <ecrit@ietfa.amsl.com>; Wed, 1 Jul 2015 06:41:46 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5D7F1A21B8 for <ecrit@ietf.org>; Wed, 1 Jul 2015 06:41:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1435758107; x=1467294107; h=from:message-id:in-reply-to:references:date:to:subject: cc:mime-version:content-transfer-encoding; bh=QkXefTA0mOFeQMS298oMtjhpivGIyXNI+ZBtZhERgqM=; b=Btbvj8JlePvTrZYNcocGk3O1UiFukupx59T+TgmgYspy01hlYY2+oALN UHFCvXyxHBsFj8FIe+ozMIEkqk1RWOGbmPZKp/TmutDM4dD/OYIXujZ8g hM28jMhAypLI4+5420Brn10hkitPBVWDERaKW+vppYCP99pFhh21ifugL I=;
X-IronPort-AV: E=McAfee;i="5700,7163,7848"; a="92900460"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jul 2015 06:41:46 -0700
From: Randall Gellens <randy@qti.qualcomm.com>
X-IronPort-AV: E=Sophos;i="5.15,385,1432623600"; d="scan'208";a="949467564"
Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 01 Jul 2015 06:41:45 -0700
Received: from [65.122.198.41] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 1 Jul 2015 06:41:44 -0700
Message-ID: <p06240600d1b99e2e62fe@[65.122.198.41]>
In-Reply-To: <p06240602d169790eafa6@[99.111.97.136]> <p06240600d194f63d737f@[99.111.97.136]>
References: <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> <949EF20990823C4C85C18D59AA11AD8B6970D7F0@FR712WXCHMBA11.zeu.alcatel- l ucent.com> <p06240602d169790eafa6@[99.111.97.136]> <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> <p06240600d194f63d737f@[99.111.97.136]>
X-Mailer: Eudora for Mac OS X
Date: Wed, 01 Jul 2015 06:41:42 -0700
To: Alissa Cooper <alissa@cooperw.in>, "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To nasanexm02f.na.qualcomm.com (10.85.0.87)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ecrit/Fzzqpb8-CwUHkmuPq_UL6fir4RE>
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] AD review: draft-ietf-ecrit-additional-data-29
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 01 Jul 2015 13:41:51 -0000

Hi Alissa and Keith,

Version -30 is now published and contains all 
changes addressing all comments from both of you.

Thanks again for your reviews, I and my fellow authors appreciate it.


At 6:55 PM -0700 6/28/15, Randall Gellens wrote:

>  Hi Keith,
>
>  Thanks for your comments.  I've addressed them 
> in-line below, and changes are in -30.
>
>  At 11:45 AM +0000 5/1/15, Keith (Keith) DRAGE wrote:
>
>>   This part of Alissa's review caught my eye 
>> because I think the original intent is wrong, 
>> and therefore so is the rewrite:
>  ...snip...
>>      header of a SIP message. It has no meaning 
>> outside the context of an emergency call."
>
>  The intent is not interoperability per se but 
> rather protection.  The original text was 
> trying to say "It's a really bad idea to send 
> this data in anything other than an emergency 
> call."  It's also true that a purpose value 
> starting with 'EmergencyCallData.' is only 
> defined for use within an emergency call; use 
> outside this context is a Bad Idea as well as 
> undefined.  Although there is an exception, 
> which is private emergency call, e.g., the call 
> leg between a vehicle and a service provider 
> call center, but that's a private use between 
> endpoints by prior agreement.  Another 
> exception to Keith's proposed text is a test 
> call.
>
>  I added a modified form of Keith's text:
>
>      A Call-info header with a purpose value starting with
>      'EmergencyCallData' only has meaning in the context of an
>      emergency call (including test emergency calls); use in other
>      contexts is undefined and is likely to unnecessarily expose
>      confidential data
>
>>   As a result of opening the document again I 
>> also noted the following that would be worthy 
>> of comment.
>>
>>   Section 4.2.3:
>>
>>   OLD TEXT
>  ...snip...
>>   What is the real requirement here, does it 
>> apply to something within the scope of this 
>> document, and can it be tested.
>
>  The intent of the text is to specify that 
> dereferencing results in a standardized data 
> structure, which is necessary for 
> interoperability; it wasn't intended to require 
> that the reference remain valid for some period 
> of time, although since you bring it up, it 
> would be reasonable to require that it remain 
> valid for a specific period of time after 
> termination of the call.
>
>>   Section 5
>>   -----------
>>
>>   OLD TEXT
>>
>>   Every block must be
>>      one of the types in the registry.
>>
>>   As specified this can be confused ...
>>  ...snip...
>>  ... in the document. I assume "service type". I would suggest.
>>
>>   "All service types used in blocks are expected to be registered"
>
>  It means the type of data block, that is, which 
> data block, as registered in the Emergency Call 
> Data Types Registry.  The document defines a 
> set of data blocks and establishes a registry 
> so that the set can be expanded.  The text is 
> trying to say that any of the set of data 
> blocks may be sent, and only registered blocks 
> can be sent, for interoperability (the receiver 
> must know how to interpret the blocks).
>
>>   But it is dubious whether we need any 
>> sentence at all rather than the implicit one 
>> that says "If a registry is provided for an 
>> element then all values are expected to be 
>> registered".
>
>  It's the corollary of the previous sentence; 
> that is: "One or more blocks [of the registered 
> set of blocks] may be sent.  Every block must 
> be [a member of the set]"
>
>  I've reworded the text to be:
>
>     One or more blocks of data registered in the Emergency Call
>     Additional Data registry, as defined in Section 10.1.9, can be
>     included or referenced in the SIP signaling (using the Call-Info
>     header field) or in the <provided-by> element of a PIDF-LO.  For
>     interoperability, only blocks in the registry are permitted to be
>     sent using the mechanisms specified in this document.
>
>>   Section 9
>>   ----------
>>
>>   OLD TEXT
>>
>>   Local regulations
>>      may govern what data must be provided in emergency calls, but in
>>      general, the emergency call system is aided by the information
>>      described in this document.
>>
>>   /must be/is/
>
>  Agreed.
>
>>   Section 10.1.9
>>   --------------
>>
>>   OLD TEXT
>>
>>   This document creates a new sub-registry called 'Device/Service Data
>>  ...snip...
>>  ... details about what the implicit expert 
>> review associated with this policy requires.
>>
>>   Similar comments apply elsewhere e.g. 10.1.10
>
>  Agreed, done.
>
>>   Like Alissa I would prefer that all the 
>> material that IANA has to deal with is within 
>> the IANA considerations sections, and not 
>> referenced back to other parts of the document 
>> (even if that means duplication of text).
>
>  Alissa asked that the initial values all be in 
> one place, either all in the block definitions, 
> or all in the IANA section.  After discussing 
> with my coauthors, we decided the best approach 
> is to have all tables in the block definitions.
>
>>   Section 10.2
>>   ------------
>>
>>   TEXT
>>
>>   Note that 'EmergencyCallData'
>>      is a compound value; when used as a value of the 'purpose' parameter
>  ...snip...
>>      registry Section 10.1.10.
>>
>>   This text would appear to be nothing to do 
>> with the registry or the values placed in the 
>> registry.
>
>  The text is adding a new value to the 'purpose' 
> parameter value registry.  The fact that the 
> new value is compound is significant.
>
>>   Other comment
>>   -------------
>>
>>   RFC 3261 contains the statement in section 16.6.
>>
>>   The proxy MUST NOT add to, modify,
>>  ...snip...
>>  ... and not add to the body. In order to add 
>> to the body it must be a B2BUA. This should be 
>> identified somewhere in the document.
>
>  I've added text to this effect in section 5.1
>
>>>   -----Original Message-----
>>>   From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Alissa Cooper
>>>   Sent: 30 April 2015 23:57
>  ...snip...
>>   _______________________________________________
>>   Ecrit mailing list
>>   Ecrit@ietf.org
>>   https://www.ietf.org/mailman/listinfo/ecrit
>

At 6:53 PM -0700 6/28/15, Randall Gellens wrote:

>  At 3:56 PM -0700 4/30/15, Alissa Cooper wrote:
>
>>   I have reviewed 
>> draft-ietf-ecrit-additional-data-29 in 
>> preparation for IETF last call. There are a 
>> number of issues that need to be resolved 
>> before the IETF LC can be issued, which IÕve 
>> included below as substantive comments and 
>> questions. There is a list of nits at the end 
>> that also need to be fixed.
>
>  Thank you very much, I appreciate it.  I've 
> addressed them below and the -30 has the 
> changes.
>
>>   Substantive comments and questions:
>>
>>   General:
>>   I've asked the shepherd to validate all of 
>> the XML in the document and am waiting to hear 
>> back on that.
>
>  This is in progress; several small errors have 
> been identified and fixed so far.
>
>>   Section 1:
>>   I would suggest adding this text from Section 
>> 9 or something like it at the end of the 
>> introduction:
>  ...snip...
>>      of an emergency call is a trade-off to protect the greater interest
>>      of the customer in an emergency."
>
>  I agree, done.
>
>>   Section 4.1:
>>   I am a little confused about how this section 
>> applies when the data is being provided by the 
>> device. First, this ...
>>  ...snip...
>>   I think this would be clearer if the first 
>> sentence said "any service provider in the 
>> path of the call, the access network provider, 
>> or the device."
>
>  I agree, done.
>
>>   Then later in the section Data Provider ID, 
>> Data Provider ID Series, and Type of Data 
>> Provider are defined. None of these seem ...
>>  ...snip...
>>  ... Section 6 that only Type of Data Provider 
>> is included, and is listed as ÒOther,Ó which 
>> seems less specific than it ideally could be.
>
>  In reviewing the various elements in this 
> block, I saw that in some cases there was text 
> explaining how the element is set by the device 
> but not in all cases.  I have added text where 
> it was missing and clarified some of the other 
> text. In the Type of Data Provider registry, I 
> expanded the description of the "client" value 
> to be "Originating client/device" to make it 
> clear that this is the appropriate value when 
> set by the device.
>
>>   Section 4.1.2:
>>   Is there an EENA equivalent of the NENA 
>> company ID? If so, it should be mentioned here.
>
>  I am not aware that EENA has yet established 
> such a registry, but the 'EENA' value is 
> present in anticipation.
>
>>   Is it the case that where a 
>> jurisdiction-specific ID exists, it is 
>> preferred over an FQDN? If so, that should be 
>> stated explicitly.
>
>  Thanks, I have clarified the text to try to make this very clear.
>
>>   Section 4.1.5:
>>   "If the call is from a device, this SHOULD be the contact
>>         information of the owner of the device."
>>
>>   What are the exception cases for this SHOULD? 
>> What should this element be if it is not the 
>> owner's contact info?
>
>  Normally, the device owner and user are the 
> same, but when they are different, the contact 
> info SHOULD be for the user, but MAY be for the 
> owner. I have clarified the text to make this 
> more clear.
>
>>   Section 4.1.6:
>>   By saying the other language tags are 
>> independent of this language element, does 
>> that mean they should be ignored? If so, that 
>> should be stated explicitly.
>
>  It's not that anything is being ignored, it's 
> that these are entirely separate things.  The 
> field in 4.1.6 is for information to a human: 
> it informs the PSAP person who needs to contact 
> the data provider as to the language(s) used by 
> the data provider.  If the PSAP needs to 
> contact the data provider, it can be helpful to 
> know in advance the language(s).  If the PSAP 
> uses a communication protocol to reach the data 
> provider, that protocol may have language 
> facilities of its own, and if so, those are 
> independent of this field.  I've clarified the 
> text.
>
>>   Section 4.1.9:
>>   "This element is required if the Data Provider
>>         type is set to "Subcontractor"."
>>
>>   Subcontractor is not listed as a data 
>> provider type in section 4.1.4, so this 
>> doesn't quite make sense.
>
>  This is supposed to say "This data is required 
> if the entity providing the data is a 
> subcontractor."  Thanks.
>
>>   Section 4.2.1:
>>   Shouldn't "use" be listed as conditional?
>
>  Yes, I agree it is more clear that way.
>
>>   Section 4.2.3:
>>   s/MUST NOT/ought not to/
>
>  Yes, I agree.
>
>>   Section 4.3.4:
>>   I'm curious about the kinds of 
>> "investigations" that PSAPs do and how they 
>> have used unique device IDs in those 
>> investigations -- could you explain? At first 
>> blush this seems to require over-sharing of 
>> sensitive data.
>
>  The most common situation that I'm aware of is 
> repeated false/accidental calls.  If there is 
> no callback number or it isn't usable, the PSAP 
> may need to try and track down the device by 
> contacting the service providers in the area. 
> In the case of handsets without current 
> service, they may be able to determine who last 
> had service.  There could be other situations 
> where this might be useful (e.g., a 
> disconnected call where the call taker believes 
> there is a need for assistance but was not able 
> to obtain a location or other information).
>
>>   Section 4.4.1:
>>   Are there any jurisdiction-specific rules you 
>> can point to that would indicate that having a 
>> single boolean "privacy ...
>>  ...snip...
>>  ... least some places have well-specified 
>> rules for what to do when they receive this 
>> value), this indicator seems pretty hand-wavy.
>
>  I know it's messy to have a single 'privacy' 
> flag whose interpretation is left to each 
> jurisdiction, but this exactly matches the 
> semantics of the equivalent privacy indicator 
> provided in some legacy emergency call systems. 
> I've added some text to this effect.
>
>>   Section 4.4.2:
>>   Are there any xCard fields you would 
>> recommend not sending for lack of relevance 
>> (e.g., anniversary)?
>
>  That's a good question.  The answer is that 
> name, address, and phone number(s) are the 
> minimum, but anything else might potentially be 
> useful in some circumstances.  I've added text 
> to this effect.
>
>>   Depending on what the answer is to my 
>> question in 4.1.6 about interaction between 
>> Data Provider Language(s) and language tags, 
>> there might need to be text in this section as 
>> well about expected behavior when both are 
>> present and when the data provider is the 
>> device.
>
>  Since these are entirely separate and don't 
> interact, and I've added clarifying text in 
> 4.1.6, I don't think anything here is needed, 
> although I'm open to adding additional 
> clarifying text here if you think it helpful.
>
>>   Section 5.1:
>>   The last paragraph here makes it sound as 
>> though additional data is required to be sent 
>> on every emergency call ...
>>  ...snip...
>>  ... in the document, preferably in the 
>> introduction. If not, the normative language 
>> in the last paragraph here needs to be fixed.
>
>  The intent is that every emergency call carry 
> the information described here using the 
> mechanisms described here.  I've added text to 
> this effect in both the Abstract and the 
> Introduction. Thanks for pointing out that it 
> wasn't clear that this is the intent.
>
>>   Section 6:
>>   The owner/subscriber of this laptop is Hannes 
>> Tschofenig. His contact tel URI is in North 
>> America but his work and ...
>>  ...snip...
>>  ... require more narrative explanation in the 
>> text. Alternatively, a simpler or more 
>> plausible example might help readers out more.
>
>  Wow, I'm quite impressed that you went to this 
> much work!  I never expected anyone to pull out 
> each of these parts from an example, put them 
> together, and see if they were internally 
> consistent.  The least I can do is try to 
> improve it, so I added 'home' entries to the 
> xCard for <addr>, <tel>, and <geo> for a 
> location within the U.S. to the device-provided 
> info, moved the VoIP provider from London to 
> Iowa (with appropriate address and time zone 
> information), switched the PIDF-LO from the 
> access network to be a U.S. address, and 
> switched the access network provider to be an 
> Access Network type rather than "other".
>
>>   Section 8:
>>   "Mechanisms that
>>      protect against eavesdropping (such as Transport Layer Security
>  ...snip...
>>   s/Service providers SHOULD choose the 
>> latter/Service providers ought to choose the 
>> latter/
>>   (otherwise this reads like a normative requirement on IMS functionality)
>
>  Thanks very much for these comments, I've made 
> corrections to section 8 for all of them.
>
>>   Section 10.1.1:
>>   "Private entities issuing and using internally-generated IDs are
>>      encouraged to register and use a unique identifier."
>>
>>   What is meant by "use a unique identifier"?
>
>  The idea is that some organizations, such as 
> NENA, issue IDs that are unique among all IDs 
> they issue, so a combination of the NENA ID and 
> the fact that it is from NENA is globally 
> unique. Other entities may not have an ID 
> issued by an organization such as NENA, so they 
> are permitted to use their domain name.  I've 
> reworded the text to try and make this more 
> clear.
>
>>   Section 10.1.8:
>>   It might be useful to give the experts some 
>> additional criteria around weighing privacy 
>> vs. utility trade-offs ...
>>  ...snip...
>>  ... to authenticate a device as a device ID 
>> and few or no PSAPs can actually make use of 
>> it, that may argue against registering it.
>
>  I think the text "The expert should ascertain 
> that ... the information [is] useful to PSAPs 
> and responders to uniquely identify a device" 
> would disallow a biometric fingerprint (since 
> it isn't useful for a PSAP, but I'm happy to 
> add more clarifying text here.
>
>>   Section 12.2:
>>   I think RFC 3966 should be a normative reference.
>
>  OK.
>
>>   Nits:
>>
>>   General:
>>   Why are some of the registry tables in the 
>> main sections of the document and others are 
>> in the IANA Considerations section? Seems like 
>> they should all be one or the other.
>
>  I moved all the tables to be in the block definitions.
>
>>   Section 2:
>>   Citations for vCard and xCard should be added to the last paragraph.
>
>  Agreed, done.
>
>>   Section 4.1.7:
>>   This sentence seems redundant: "For encoding of the xCard this
>>         specification uses the XML-based encoding specified in [RFC6351],
>>         referred to in this document as "xCard"."
>
>  Yes, it should say "For encoding of the vCard."
>
>>    ÊÊÊÊ
>>   Section 4.2.1:
>>   s/therefore this is/this is/
>
>  Done
>
>>   s/Figure 22/Section 10.1.2/
>
>  Done
>
>>   Section 4.2.2:
>>   s/Figure 3/Section 10.1.3/
>
>  Done
>
>>   Section 4.2.3:
>>   s/Figure 23/Section 10.1.4/
>
>  Done
>
>>   Section 4.3.6:
>>   A reference to the IEEE 1512 spec should be included.
>
>  Done
>
>>   Section 4.3.7:
>>   s/which allow/that allow/
>
>  Done
>
>>   "Some standards being developed by other 
>> organizations" -- would be good to provide 
>> citations.
>
>  I reworded the text to be simpler and avoid the reference.
>
>>   Section 4.4.2:
>>   Given that 4.4 says the location provided 
>> here is the contact address and not 
>> necessarily the location of the caller, it 
>> seems like this section needs to explain a 
>> little more why a call taker would use the 
>> location provided here.
>
>  I agree, and added some additional text.
>
>>   Section 5.1:
>>   OLD
>>   A Call-info header with a purpose value starting with
>>      'EmergencyCallData' MUST only be sent on an emergency call
>>   NEW
>>   A Call-info header with a purpose value starting with
>>      'EmergencyCallData' MUST NOT be sent 
>> unless the call is an emergency call
>
>  Edited per Keith's reply to your comment.
>
>>    Ê
>>   Section 9:
>>   s/The functionality defined in this document, 
>> however/The functionality defined in this 
>> document/
>
>  Done.
>
>>   Section 10.1.2:
>>   s/A s[RFC4119]hort/A short/
>
>  Previously fixed.
>
>>   Section 10.1.5:
>>   Seems like this section and Figure 1 should 
>> both use "Token" rather than "Tokenproviderid."
>
>  Yes, done.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
No one expects Braniff to go broke. No major U.S. carrier ever has.
        --The Wall Street Journal, 30 July 1980.