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.
- [Ecrit] AD review: draft-ietf-ecrit-additional-da… Alissa Cooper
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… DRAGE, Keith (Keith)
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Randall Gellens
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Randall Gellens
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Randall Gellens
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Randall Gellens
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Alissa Cooper
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Randall Gellens
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Alissa Cooper
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Rosen, Brian
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Randall Gellens
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Alissa Cooper
- Re: [Ecrit] AD review: draft-ietf-ecrit-additiona… Randall Gellens