From nobody Wed Jul 1 06:41:52 2015 Return-Path: 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 ; 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 ; 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 ; 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 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: In-Reply-To: References: <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> <949EF20990823C4C85C18D59AA11AD8B6970D7F0@FR712WXCHMBA11.zeu.alcatel- l ucent.com> <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> X-Mailer: Eudora for Mac OS X Date: Wed, 1 Jul 2015 06:41:42 -0700 To: Alissa Cooper , "DRAGE, Keith (Keith)" 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: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=20 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=20 > 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=20 >> because I think the original intent is wrong,=20 >> and therefore so is the rewrite: > ...snip... >> header of a SIP message. It has no meaning=20 >> outside the context of an emergency call." > > The intent is not interoperability per se but=20 > rather protection. The original text was=20 > trying to say "It's a really bad idea to send=20 > this data in anything other than an emergency=20 > call." It's also true that a purpose value=20 > starting with 'EmergencyCallData.' is only=20 > defined for use within an emergency call; use=20 > outside this context is a Bad Idea as well as=20 > undefined. Although there is an exception,=20 > which is private emergency call, e.g., the call=20 > leg between a vehicle and a service provider=20 > call center, but that's a private use between=20 > endpoints by prior agreement. Another=20 > exception to Keith's proposed text is a test=20 > 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=20 >> also noted the following that would be worthy=20 >> of comment. >> >> Section 4.2.3: >> >> OLD TEXT > ...snip... >> What is the real requirement here, does it=20 >> apply to something within the scope of this=20 >> document, and can it be tested. > > The intent of the text is to specify that=20 > dereferencing results in a standardized data=20 > structure, which is necessary for=20 > interoperability; it wasn't intended to require=20 > that the reference remain valid for some period=20 > of time, although since you bring it up, it=20 > would be reasonable to require that it remain=20 > valid for a specific period of time after=20 > 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=20 > data block, as registered in the Emergency Call=20 > Data Types Registry. The document defines a=20 > set of data blocks and establishes a registry=20 > so that the set can be expanded. The text is=20 > trying to say that any of the set of data=20 > blocks may be sent, and only registered blocks=20 > can be sent, for interoperability (the receiver=20 > must know how to interpret the blocks). > >> But it is dubious whether we need any=20 >> sentence at all rather than the implicit one=20 >> that says "If a registry is provided for an=20 >> element then all values are expected to be=20 >> registered". > > It's the corollary of the previous sentence;=20 > that is: "One or more blocks [of the registered=20 > set of blocks] may be sent. Every block must=20 > 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 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=20 >> 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=20 >> material that IANA has to deal with is within=20 >> the IANA considerations sections, and not=20 >> referenced back to other parts of the document=20 >> (even if that means duplication of text). > > Alissa asked that the initial values all be in=20 > one place, either all in the block definitions,=20 > or all in the IANA section. After discussing=20 > with my coauthors, we decided the best approach=20 > 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=20 >> with the registry or the values placed in the=20 >> registry. > > The text is adding a new value to the 'purpose'=20 > parameter value registry. The fact that the=20 > 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=20 >> to the body it must be a B2BUA. This should be=20 >> 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=20 >> draft-ietf-ecrit-additional-data-29 in=20 >> preparation for IETF last call. There are a=20 >> number of issues that need to be resolved=20 >> before the IETF LC can be issued, which I=D5ve=20 >> included below as substantive comments and=20 >> questions. There is a list of nits at the end=20 >> that also need to be fixed. > > Thank you very much, I appreciate it. I've=20 > addressed them below and the -30 has the=20 > changes. > >> Substantive comments and questions: >> >> General: >> I've asked the shepherd to validate all of=20 >> the XML in the document and am waiting to hear=20 >> back on that. > > This is in progress; several small errors have=20 > been identified and fixed so far. > >> Section 1: >> I would suggest adding this text from Section=20 >> 9 or something like it at the end of the=20 >> 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=20 >> applies when the data is being provided by the=20 >> device. First, this ... >> ...snip... >> I think this would be clearer if the first=20 >> sentence said "any service provider in the=20 >> path of the call, the access network provider,=20 >> or the device." > > I agree, done. > >> Then later in the section Data Provider ID,=20 >> Data Provider ID Series, and Type of Data=20 >> Provider are defined. None of these seem ... >> ...snip... >> ... Section 6 that only Type of Data Provider=20 >> is included, and is listed as =D2Other,=D3 which=20 >> seems less specific than it ideally could be. > > In reviewing the various elements in this=20 > block, I saw that in some cases there was text=20 > explaining how the element is set by the device=20 > but not in all cases. I have added text where=20 > it was missing and clarified some of the other=20 > text. In the Type of Data Provider registry, I=20 > expanded the description of the "client" value=20 > to be "Originating client/device" to make it=20 > clear that this is the appropriate value when=20 > set by the device. > >> Section 4.1.2: >> Is there an EENA equivalent of the NENA=20 >> company ID? If so, it should be mentioned here. > > I am not aware that EENA has yet established=20 > such a registry, but the 'EENA' value is=20 > present in anticipation. > >> Is it the case that where a=20 >> jurisdiction-specific ID exists, it is=20 >> preferred over an FQDN? If so, that should be=20 >> 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?=20 >> What should this element be if it is not the=20 >> owner's contact info? > > Normally, the device owner and user are the=20 > same, but when they are different, the contact=20 > info SHOULD be for the user, but MAY be for the=20 > owner. I have clarified the text to make this=20 > more clear. > >> Section 4.1.6: >> By saying the other language tags are=20 >> independent of this language element, does=20 >> that mean they should be ignored? If so, that=20 >> should be stated explicitly. > > It's not that anything is being ignored, it's=20 > that these are entirely separate things. The=20 > field in 4.1.6 is for information to a human:=20 > it informs the PSAP person who needs to contact=20 > the data provider as to the language(s) used by=20 > the data provider. If the PSAP needs to=20 > contact the data provider, it can be helpful to=20 > know in advance the language(s). If the PSAP=20 > uses a communication protocol to reach the data=20 > provider, that protocol may have language=20 > facilities of its own, and if so, those are=20 > independent of this field. I've clarified the=20 > 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=20 >> provider type in section 4.1.4, so this=20 >> doesn't quite make sense. > > This is supposed to say "This data is required=20 > if the entity providing the data is a=20 > 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=20 >> "investigations" that PSAPs do and how they=20 >> have used unique device IDs in those=20 >> investigations -- could you explain? At first=20 >> blush this seems to require over-sharing of=20 >> sensitive data. > > The most common situation that I'm aware of is=20 > repeated false/accidental calls. If there is=20 > no callback number or it isn't usable, the PSAP=20 > may need to try and track down the device by=20 > contacting the service providers in the area.=20 > In the case of handsets without current=20 > service, they may be able to determine who last=20 > had service. There could be other situations=20 > where this might be useful (e.g., a=20 > disconnected call where the call taker believes=20 > there is a need for assistance but was not able=20 > to obtain a location or other information). > >> Section 4.4.1: >> Are there any jurisdiction-specific rules you=20 >> can point to that would indicate that having a=20 >> single boolean "privacy ... >> ...snip... >> ... least some places have well-specified=20 >> rules for what to do when they receive this=20 >> value), this indicator seems pretty hand-wavy. > > I know it's messy to have a single 'privacy'=20 > flag whose interpretation is left to each=20 > jurisdiction, but this exactly matches the=20 > semantics of the equivalent privacy indicator=20 > provided in some legacy emergency call systems.=20 > I've added some text to this effect. > >> Section 4.4.2: >> Are there any xCard fields you would=20 >> recommend not sending for lack of relevance=20 >> (e.g., anniversary)? > > That's a good question. The answer is that=20 > name, address, and phone number(s) are the=20 > minimum, but anything else might potentially be=20 > useful in some circumstances. I've added text=20 > to this effect. > >> Depending on what the answer is to my=20 >> question in 4.1.6 about interaction between=20 >> Data Provider Language(s) and language tags,=20 >> there might need to be text in this section as=20 >> well about expected behavior when both are=20 >> present and when the data provider is the=20 >> device. > > Since these are entirely separate and don't=20 > interact, and I've added clarifying text in=20 > 4.1.6, I don't think anything here is needed,=20 > although I'm open to adding additional=20 > clarifying text here if you think it helpful. > >> Section 5.1: >> The last paragraph here makes it sound as=20 >> though additional data is required to be sent=20 >> on every emergency call ... >> ...snip... >> ... in the document, preferably in the=20 >> introduction. If not, the normative language=20 >> in the last paragraph here needs to be fixed. > > The intent is that every emergency call carry=20 > the information described here using the=20 > mechanisms described here. I've added text to=20 > this effect in both the Abstract and the=20 > Introduction. Thanks for pointing out that it=20 > wasn't clear that this is the intent. > >> Section 6: >> The owner/subscriber of this laptop is Hannes=20 >> Tschofenig. His contact tel URI is in North=20 >> America but his work and ... >> ...snip... >> ... require more narrative explanation in the=20 >> text. Alternatively, a simpler or more=20 >> plausible example might help readers out more. > > Wow, I'm quite impressed that you went to this=20 > much work! I never expected anyone to pull out=20 > each of these parts from an example, put them=20 > together, and see if they were internally=20 > consistent. The least I can do is try to=20 > improve it, so I added 'home' entries to the=20 > xCard for , , and for a=20 > location within the U.S. to the device-provided=20 > info, moved the VoIP provider from London to=20 > Iowa (with appropriate address and time zone=20 > information), switched the PIDF-LO from the=20 > access network to be a U.S. address, and=20 > switched the access network provider to be an=20 > 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=20 >> latter/Service providers ought to choose the=20 >> latter/ >> (otherwise this reads like a normative requirement on IMS functionality= ) > > Thanks very much for these comments, I've made=20 > 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=20 > NENA, issue IDs that are unique among all IDs=20 > they issue, so a combination of the NENA ID and=20 > the fact that it is from NENA is globally=20 > unique. Other entities may not have an ID=20 > issued by an organization such as NENA, so they=20 > are permitted to use their domain name. I've=20 > reworded the text to try and make this more=20 > clear. > >> Section 10.1.8: >> It might be useful to give the experts some=20 >> additional criteria around weighing privacy=20 >> vs. utility trade-offs ... >> ...snip... >> ... to authenticate a device as a device ID=20 >> and few or no PSAPs can actually make use of=20 >> it, that may argue against registering it. > > I think the text "The expert should ascertain=20 > that ... the information [is] useful to PSAPs=20 > and responders to uniquely identify a device"=20 > would disallow a biometric fingerprint (since=20 > it isn't useful for a PSAP, but I'm happy to=20 > 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=20 >> main sections of the document and others are=20 >> in the IANA Considerations section? Seems like=20 >> 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." > >> =CA=CA=CA=CA >> 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=20 >> organizations" -- would be good to provide=20 >> citations. > > I reworded the text to be simpler and avoid the reference. > >> Section 4.4.2: >> Given that 4.4 says the location provided=20 >> here is the contact address and not=20 >> necessarily the location of the caller, it=20 >> seems like this section needs to explain a=20 >> little more why a call taker would use the=20 >> 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=20 >> unless the call is an emergency call > > Edited per Keith's reply to your comment. > >> =CA >> Section 9: >> s/The functionality defined in this document,=20 >> however/The functionality defined in this=20 >> 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=20 >> 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. From nobody Wed Jul 1 06:55:50 2015 Return-Path: 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 05F691A8960 for ; Wed, 1 Jul 2015 06:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 T5xNpBU6ZKPb for ; Wed, 1 Jul 2015 06:55:43 -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 108FE1A8965 for ; Wed, 1 Jul 2015 06:55:42 -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=1435758943; x=1467294943; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=+a8I4oey4Cj/Y+Mc59WftsM7YdSgFCC+AjtPRqTGJPs=; b=Xx5hruBBYBYXgpVSVGm/nyvJwMEt85q8FCczyBdwPaInJfzhzGw93So7 iyOBJFNHA+7e5GT33ZyJZQCJXJW8FLWYuPB6spQ12k8FdXZmwDb954A3c R9fPNyCa8IDoKgzSgvhZj5Eo6u0uZDtc+ItazkgieOKPoVg7D5aMSy5HC o=; X-IronPort-AV: E=McAfee;i="5700,7163,7848"; a="92900849" 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:55:42 -0700 X-IronPort-AV: E=Sophos;i="5.15,385,1432623600"; d="scan'208";a="949474597" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 01 Jul 2015 06:55:42 -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:55:40 -0700 Message-ID: In-Reply-To: References: <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> <949EF20990823C4C85C18D59AA11AD8B6970D7F0@FR712WXCHMBA11.zeu.alcatel- l ucent.com> <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> X-Mailer: Eudora for Mac OS X Date: Wed, 1 Jul 2015 06:55:38 -0700 To: Alissa Cooper , "DRAGE, Keith (Keith)" From: Randall Gellens 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-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.85.0.33) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 13:55:49 -0000 Also, Hannes has verified the XML examples=20 against the schemas. There is a new Appendix B=20 with some notes on what is required (e.g., due to=20 line breaks/whitespace introduced by I-D/RFC=20 format), At 6:41 AM -0700 7/1/15, Randall Gellens wrote: > Hi Alissa and Keith, > > Version -30 is now published and contains all=20 > changes addressing all comments from both of=20 > 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=20 >> 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=20 >>> because I think the original intent is wrong,=20 >>> and therefore so is the rewrite: >> ...snip... >>> header of a SIP message. It has no=20 >>> meaning outside the context of an emergency=20 >>> call." >> >> The intent is not interoperability per se but=20 >> rather protection. The original text was=20 >> trying to say "It's a really bad idea to send=20 >> this data in anything other than an emergency=20 >> call." It's also true that a purpose value=20 >> starting with 'EmergencyCallData.' is only=20 >> defined for use within an emergency call; use=20 >> outside this context is a Bad Idea as well as=20 >> undefined. Although there is an exception,=20 >> which is private emergency call, e.g., the=20 >> call leg between a vehicle and a service=20 >> provider call center, but that's a private use=20 >> between endpoints by prior agreement. Another=20 >> exception to Keith's proposed text is a test=20 >> 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=20 >>> also noted the following that would be worthy=20 >>> of comment. >>> >>> Section 4.2.3: >>> >>> OLD TEXT >> ...snip... >>> What is the real requirement here, does it=20 >>> apply to something within the scope of this=20 >>> document, and can it be tested. >> >> The intent of the text is to specify that=20 >> dereferencing results in a standardized data=20 >> structure, which is necessary for=20 >> interoperability; it wasn't intended to=20 >> require that the reference remain valid for=20 >> some period of time, although since you bring=20 >> it up, it would be reasonable to require that=20 >> it remain valid for a specific period of time=20 >> 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,=20 >> which data block, as registered in the=20 >> Emergency Call Data Types Registry. The=20 >> document defines a set of data blocks and=20 >> establishes a registry so that the set can be=20 >> expanded. The text is trying to say that any=20 >> of the set of data blocks may be sent, and=20 >> only registered blocks can be sent, for=20 >> interoperability (the receiver must know how=20 >> to interpret the blocks). >> >>> But it is dubious whether we need any=20 >>> sentence at all rather than the implicit one=20 >>> that says "If a registry is provided for an=20 >>> element then all values are expected to be=20 >>> registered". >> >> It's the corollary of the previous sentence;=20 >> that is: "One or more blocks [of the=20 >> registered set of blocks] may be sent. Every=20 >> 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 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=20 >>> 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=20 >>> material that IANA has to deal with is within=20 >>> the IANA considerations sections, and not=20 >>> referenced back to other parts of the=20 >>> document (even if that means duplication of=20 >>> text). >> >> Alissa asked that the initial values all be=20 >> in one place, either all in the block=20 >> definitions, or all in the IANA section.=20 >> After discussing with my coauthors, we decided=20 >> the best approach is to have all tables in the=20 >> block definitions. >> >>> Section 10.2 >>> ------------ >>> >>> TEXT >>> >>> Note that 'EmergencyCallData' >>> is a compound value; when used as a value of the 'purpose' paramet= er >> ...snip... >>> registry Section 10.1.10. >>> >>> This text would appear to be nothing to do=20 >>> with the registry or the values placed in the=20 >>> registry. >> >> The text is adding a new value to the=20 >> 'purpose' parameter value registry. The fact=20 >> 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=20 >>> to the body it must be a B2BUA. This should=20 >>> 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 Coop= er >>>> 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=20 >>> draft-ietf-ecrit-additional-data-29 in=20 >>> preparation for IETF last call. There are a=20 >>> number of issues that need to be resolved=20 >>> before the IETF LC can be issued, which I=D5ve=20 >>> included below as substantive comments and=20 >>> questions. There is a list of nits at the end=20 >>> that also need to be fixed. >> >> Thank you very much, I appreciate it. I've=20 >> addressed them below and the -30 has the=20 >> changes. >> >>> Substantive comments and questions: >>> >>> General: >>> I've asked the shepherd to validate all of=20 >>> the XML in the document and am waiting to=20 >>> hear back on that. >> >> This is in progress; several small errors=20 >> have been identified and fixed so far. >> >>> Section 1: >>> I would suggest adding this text from=20 >>> Section 9 or something like it at the end of=20 >>> the introduction: >> ...snip... >>> of an emergency call is a trade-off to protect the greater interes= t >>> of the customer in an emergency." >> >> I agree, done. >> >>> Section 4.1: >>> I am a little confused about how this=20 >>> section applies when the data is being=20 >>> provided by the device. First, this ... >>> ...snip... >>> I think this would be clearer if the first=20 >>> sentence said "any service provider in the=20 >>> path of the call, the access network=20 >>> provider, or the device." >> >> I agree, done. >> >>> Then later in the section Data Provider ID,=20 >>> Data Provider ID Series, and Type of Data=20 >>> Provider are defined. None of these seem ... >>> ...snip... >>> ... Section 6 that only Type of Data=20 >>> Provider is included, and is listed as=20 >>> =D2Other,=D3 which seems less specific than it=20 >>> ideally could be. >> >> In reviewing the various elements in this=20 >> block, I saw that in some cases there was text=20 >> explaining how the element is set by the=20 >> device but not in all cases. I have added=20 >> text where it was missing and clarified some=20 >> of the other text. In the Type of Data=20 >> Provider registry, I expanded the description=20 >> of the "client" value to be "Originating=20 >> client/device" to make it clear that this is=20 >> the appropriate value when set by the device. >> >>> Section 4.1.2: >>> Is there an EENA equivalent of the NENA=20 >>> company ID? If so, it should be mentioned=20 >>> here. >> >> I am not aware that EENA has yet established=20 >> such a registry, but the 'EENA' value is=20 >> present in anticipation. >> >>> Is it the case that where a=20 >>> jurisdiction-specific ID exists, it is=20 >>> preferred over an FQDN? If so, that should be=20 >>> 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=20 >>> SHOULD? What should this element be if it is=20 >>> not the owner's contact info? >> >> Normally, the device owner and user are the=20 >> same, but when they are different, the contact=20 >> info SHOULD be for the user, but MAY be for=20 >> the owner. I have clarified the text to make=20 >> this more clear. >> >>> Section 4.1.6: >>> By saying the other language tags are=20 >>> independent of this language element, does=20 >>> that mean they should be ignored? If so, that=20 >>> should be stated explicitly. >> >> It's not that anything is being ignored, it's=20 >> that these are entirely separate things. The=20 >> field in 4.1.6 is for information to a human:=20 >> it informs the PSAP person who needs to=20 >> contact the data provider as to the=20 >> language(s) used by the data provider. If the=20 >> PSAP needs to contact the data provider, it=20 >> can be helpful to know in advance the=20 >> language(s). If the PSAP uses a communication=20 >> protocol to reach the data provider, that=20 >> protocol may have language facilities of its=20 >> own, and if so, those are independent of this=20 >> 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=20 >>> provider type in section 4.1.4, so this=20 >>> doesn't quite make sense. >> >> This is supposed to say "This data is=20 >> required if the entity providing the data is a=20 >> 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=20 >>> "investigations" that PSAPs do and how they=20 >>> have used unique device IDs in those=20 >>> investigations -- could you explain? At first=20 >>> blush this seems to require over-sharing of=20 >>> sensitive data. >> >> The most common situation that I'm aware of=20 >> is repeated false/accidental calls. If there=20 >> is no callback number or it isn't usable, the=20 >> PSAP may need to try and track down the device=20 >> by contacting the service providers in the=20 >> area. In the case of handsets without current=20 >> service, they may be able to determine who=20 >> last had service. There could be other=20 >> situations where this might be useful (e.g., a=20 >> disconnected call where the call taker=20 >> believes there is a need for assistance but=20 >> was not able to obtain a location or other=20 >> information). >> >>> Section 4.4.1: >>> Are there any jurisdiction-specific rules=20 >>> you can point to that would indicate that=20 >>> having a single boolean "privacy ... >>> ...snip... >>> ... least some places have well-specified=20 >>> rules for what to do when they receive this=20 >>> value), this indicator seems pretty hand-wavy. >> >> I know it's messy to have a single 'privacy'=20 >> flag whose interpretation is left to each=20 >> jurisdiction, but this exactly matches the=20 >> semantics of the equivalent privacy indicator=20 >> provided in some legacy emergency call=20 >> systems. I've added some text to this effect. >> >>> Section 4.4.2: >>> Are there any xCard fields you would=20 >>> recommend not sending for lack of relevance=20 >>> (e.g., anniversary)? >> >> That's a good question. The answer is that=20 >> name, address, and phone number(s) are the=20 >> minimum, but anything else might potentially=20 >> be useful in some circumstances. I've added=20 >> text to this effect. >> >>> Depending on what the answer is to my=20 >>> question in 4.1.6 about interaction between=20 >>> Data Provider Language(s) and language tags,=20 >>> there might need to be text in this section=20 >>> as well about expected behavior when both are=20 >>> present and when the data provider is the=20 >>> device. >> >> Since these are entirely separate and don't=20 >> interact, and I've added clarifying text in=20 >> 4.1.6, I don't think anything here is needed,=20 >> although I'm open to adding additional=20 >> clarifying text here if you think it helpful. >> >>> Section 5.1: >>> The last paragraph here makes it sound as=20 >>> though additional data is required to be sent=20 >>> on every emergency call ... >>> ...snip... >>> ... in the document, preferably in the=20 >>> introduction. If not, the normative language=20 >>> in the last paragraph here needs to be fixed. >> >> The intent is that every emergency call carry=20 >> the information described here using the=20 >> mechanisms described here. I've added text to=20 >> this effect in both the Abstract and the=20 >> Introduction. Thanks for pointing out that it=20 >> wasn't clear that this is the intent. >> >>> Section 6: >>> The owner/subscriber of this laptop is=20 >>> Hannes Tschofenig. His contact tel URI is in=20 >>> North America but his work and ... >>> ...snip... >>> ... require more narrative explanation in=20 >>> the text. Alternatively, a simpler or more=20 >>> plausible example might help readers out more. >> >> Wow, I'm quite impressed that you went to=20 >> this much work! I never expected anyone to=20 >> pull out each of these parts from an example,=20 >> put them together, and see if they were=20 >> internally consistent. The least I can do is=20 >> try to improve it, so I added 'home' entries=20 >> to the xCard for , , and for=20 >> a location within the U.S. to the=20 >> device-provided info, moved the VoIP provider=20 >> from London to Iowa (with appropriate address=20 >> and time zone information), switched the=20 >> PIDF-LO from the access network to be a U.S.=20 >> address, and switched the access network=20 >> provider to be an Access Network type rather=20 >> than "other". >> >>> Section 8: >>> "Mechanisms that >>> protect against eavesdropping (such as Transport Layer Security >> ...snip... >>> s/Service providers SHOULD choose the=20 >>> latter/Service providers ought to choose the=20 >>> latter/ >>> (otherwise this reads like a normative requirement on IMS functionali= ty) >> >> Thanks very much for these comments, I've=20 >> 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=20 >> NENA, issue IDs that are unique among all IDs=20 >> they issue, so a combination of the NENA ID=20 >> and the fact that it is from NENA is globally=20 >> unique. Other entities may not have an ID=20 >> issued by an organization such as NENA, so=20 >> they are permitted to use their domain name.=20 >> I've reworded the text to try and make this=20 >> more clear. >> >>> Section 10.1.8: >>> It might be useful to give the experts some=20 >>> additional criteria around weighing privacy=20 >>> vs. utility trade-offs ... >>> ...snip... >>> ... to authenticate a device as a device ID=20 >>> and few or no PSAPs can actually make use of=20 >>> it, that may argue against registering it. >> >> I think the text "The expert should ascertain=20 >> that ... the information [is] useful to PSAPs=20 >> and responders to uniquely identify a device"=20 >> would disallow a biometric fingerprint (since=20 >> it isn't useful for a PSAP, but I'm happy to=20 >> 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=20 >>> main sections of the document and others are=20 >>> in the IANA Considerations section? Seems=20 >>> 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." >> >>> =CA=CA=CA=CA >>> 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=20 >>> organizations" -- would be good to provide=20 >>> citations. >> >> I reworded the text to be simpler and avoid the reference. >> >>> Section 4.4.2: >>> Given that 4.4 says the location provided=20 >>> here is the contact address and not=20 >>> necessarily the location of the caller, it=20 >>> seems like this section needs to explain a=20 >>> little more why a call taker would use the=20 >>> 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=20 >>> unless the call is an emergency call >> >> Edited per Keith's reply to your comment. >> >>> =CA >>> Section 9: >>> s/The functionality defined in this=20 >>> document, however/The functionality defined=20 >>> 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=20 >>> both use "Token" rather than=20 >>> "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 mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- A day for firm decisions!!!!! Or is it? From nobody Wed Jul 1 15:59:20 2015 Return-Path: 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 8E8971A1B5A for ; Wed, 1 Jul 2015 15:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 XyoU1KcyKkjt for ; Wed, 1 Jul 2015 15:59:17 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458621A6F7C for ; Wed, 1 Jul 2015 15:59:17 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 50A2620B1D for ; Wed, 1 Jul 2015 18:59:16 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 01 Jul 2015 18:59:16 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=nPMx+Xcb6coYsjabK8NfkUsBaZM=; b=LmgHMo FFN+Bd07v0DKmr+45ZNSdQ3tFJh+WzIvN8mPycJ/M1WRHGxfuxo4ffYSFpHn31YA LxODMcpaGtTGZ0rDfczFogCUynzSDaCvOINma5+jGQTSScDLYTQ/IQKWmPUKgmgB FwDFRTqzZ/GtR74l8BITU/B84GivMyJZcYE5k= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=nPMx+Xcb6coYsja bK8NfkUsBaZM=; b=V2fRA08f+GIuSXORTHox611rQqP3yR8ll9VTK9v43eZ1fPX yD8gcwfREfIebL4vCZRTyn0E01FdEq1hdcdg+iNZU1VKmd0ScgHFUxFDQ/ka5Xhe X7rLmpqx9vBtWcNu9yLD29YmHCqE9lEd0JAS8fZ/XVqP5XeW/WqHOl7YpDQI= X-Sasl-enc: JAO+ZFXZ46DGTR+DL97Qqb8CdiZsWYiChjL3Y0CICBfb 1435791555 Received: from dhcp-171-68-20-90.cisco.com (unknown [171.68.20.90]) by mail.messagingengine.com (Postfix) with ESMTPA id 34683C00294; Wed, 1 Jul 2015 18:59:13 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01EF730DD21E@HE113667.emea1.cds.t-internal.com> Date: Wed, 1 Jul 2015 15:59:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <276B7588-3377-4900-9125-4F7729F4E530@cooperw.in> References: <6EB1BAFC-49FC-4D1F-92A2-E01C931FE92B@cisco.com> <8756CB1D-6CC2-405A-86E3-E89BDB607E81@gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01EF730DD21E@HE113667.emea1.cds.t-internal.com> To: R.Jesske@telekom.de X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-held-routing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 22:59:18 -0000 The WGLC already came and went. I=92d like to know if folks (other than the authors) have reviewed the = draft and support its publication. Thanks, Alissa On Jun 21, 2015, at 11:32 PM, R.Jesske@telekom.de wrote: > I support to proceed this draft to WGLC. >=20 > Best Regards >=20 > Roland >=20 >> On 27 May 2015, at 10:05 pm, Marc Linsner (mlinsner) = wrote: >>=20 >> All, >>=20 >> This marks the start of working group last call on this draft. = Please review and send comments to the list by COB, Wednesday June 10th, = 2015. >>=20 >> https://tools.ietf.org/html/draft-ietf-ecrit-held-routing-02 >>=20 >> Thanks, >>=20 >> Marc & Roger >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Wed Jul 1 16:18:57 2015 Return-Path: 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 D37241ACD6F for ; Wed, 1 Jul 2015 16:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 KJzlgWya3rmI for ; Wed, 1 Jul 2015 16:18:55 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658151ABD3E for ; Wed, 1 Jul 2015 16:18:55 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B984320AA4 for ; Wed, 1 Jul 2015 19:18:54 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 01 Jul 2015 19:18:54 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=10fKITngyygS/C7Ukbo5JID9Skw=; b=B4nlA0 7JYqn71N6EfRbFZVH1pTZaNBwu7kdyxtK0BQSymxPo114xspgE0rInSDP9HS+8ws LNsAUkEa5qb4z0tiB5A3HtLTMO3QCSucUFTPABVxoZYWJB5VaSl71h/msxnd1efa OXiJCZHssHzyFf/gaqupbATREL9cnp4WvRX4E= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=10fKITngyygS/C7 Ukbo5JID9Skw=; b=oENYIPblFX8vEBA4Cz1r3OESCj1RBBk+K2de51JatR5hlc3 yhrqfFe8y5DPYQKMUhzWysT9T9OJy8fFE8L/fqpVmIHE3n/fLc8Ff5In0bgu/xro wjHT3FABcYtSUh61qLN91RKoThwO+dgk3QjP/dWm/NwYCl2Ad4ePgfVWUpZk= X-Sasl-enc: Ab6Lvx43pL3UYk9gahY4aK2zDWOIaGOj7x0ddTvzcMhN 1435792734 Received: from dhcp-171-68-20-90.cisco.com (unknown [171.68.20.90]) by mail.messagingengine.com (Postfix) with ESMTPA id 9103E6800AD; Wed, 1 Jul 2015 19:18:53 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <276B7588-3377-4900-9125-4F7729F4E530@cooperw.in> Date: Wed, 1 Jul 2015 16:18:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6EB1BAFC-49FC-4D1F-92A2-E01C931FE92B@cisco.com> <8756CB1D-6CC2-405A-86E3-E89BDB607E81@gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01EF730DD21E@HE113667.emea1.cds.t-internal.com> <276B7588-3377-4900-9125-4F7729F4E530@cooperw.in> To: R.Jesske@telekom.de X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-held-routing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 23:18:57 -0000 Apologies, I sent this before seeing Keith=92s review. Thanks, Keith. Alissa On Jul 1, 2015, at 3:59 PM, Alissa Cooper wrote: > The WGLC already came and went. >=20 > I=92d like to know if folks (other than the authors) have reviewed the = draft and support its publication. >=20 > Thanks, > Alissa >=20 > On Jun 21, 2015, at 11:32 PM, R.Jesske@telekom.de wrote: >=20 >> I support to proceed this draft to WGLC. >>=20 >> Best Regards >>=20 >> Roland >>=20 >>> On 27 May 2015, at 10:05 pm, Marc Linsner (mlinsner) = wrote: >>>=20 >>> All, >>>=20 >>> This marks the start of working group last call on this draft. = Please review and send comments to the list by COB, Wednesday June 10th, = 2015. >>>=20 >>> https://tools.ietf.org/html/draft-ietf-ecrit-held-routing-02 >>>=20 >>> Thanks, >>>=20 >>> Marc & Roger >>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Wed Jul 1 23:37:53 2015 Return-Path: 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 2D2441B2F96 for ; Wed, 1 Jul 2015 23:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 oOCW_S8ptfcr for ; Wed, 1 Jul 2015 23:37:49 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846C61B2F71 for ; Wed, 1 Jul 2015 23:37:47 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail21.telekom.de with ESMTP; 02 Jul 2015 08:37:44 +0200 X-IronPort-AV: E=Sophos;i="5.15,390,1432591200"; d="scan'208";a="699601394" Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 02 Jul 2015 08:37:44 +0200 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by he110890 ([10.134.92.131]) with mapi; Thu, 2 Jul 2015 08:37:44 +0200 From: To: Date: Thu, 2 Jul 2015 08:37:43 +0200 Thread-Topic: [Ecrit] WGLC - draft-ietf-ecrit-held-routing Thread-Index: AdC0UY/FYxq5y7HiSp6DJFB16+XB6wAN7lxg Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01EF73620DF2@HE113667.emea1.cds.t-internal.com> References: <6EB1BAFC-49FC-4D1F-92A2-E01C931FE92B@cisco.com> <8756CB1D-6CC2-405A-86E3-E89BDB607E81@gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01EF730DD21E@HE113667.emea1.cds.t-internal.com> <276B7588-3377-4900-9125-4F7729F4E530@cooperw.in> In-Reply-To: <276B7588-3377-4900-9125-4F7729F4E530@cooperw.in> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-held-routing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 06:37:52 -0000 Hi Alica, so I have also reviewed the draft.=20 I went through the draft and found no technical issues and I found 3 (minor= ) Editorial issues seen from my point of view. Thus I support the publicati= on of the document. =20 1. Editorial: Section 2. Is incompasses the correct word? I found only encompa= sses in my dictionary. =20 2. Editorial: In Figure 2 the arrow for (5) Service is not correct shown withi= n the figure. 3. Section 4 after 1st Paragraph. It would be nice if the names of the elements can be mentioned explicitly. Proposal: The elements are requestRoutingInformation and routingInformation which are= defined in section 5 of this document. Thank you and Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Alissa Cooper [mailto:alissa@cooperw.in]=20 Gesendet: Donnerstag, 2. Juli 2015 00:59 An: Jesske, Roland Cc: a.james.winterbottom@gmail.com; mlinsner@cisco.com; ecrit@ietf.org Betreff: Re: [Ecrit] WGLC - draft-ietf-ecrit-held-routing The WGLC already came and went. I'd like to know if folks (other than the authors) have reviewed the draft = and support its publication. Thanks, Alissa On Jun 21, 2015, at 11:32 PM, R.Jesske@telekom.de wrote: > I support to proceed this draft to WGLC. >=20 > Best Regards >=20 > Roland >=20 >> On 27 May 2015, at 10:05 pm, Marc Linsner (mlinsner) wrote: >>=20 >> All, >>=20 >> This marks the start of working group last call on this draft. Please r= eview and send comments to the list by COB, Wednesday June 10th, 2015. >>=20 >> https://tools.ietf.org/html/draft-ietf-ecrit-held-routing-02 >>=20 >> Thanks, >>=20 >> Marc & Roger >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Thu Jul 2 02:31:59 2015 Return-Path: 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 38CE41B311A for ; Thu, 2 Jul 2015 02:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 XacaX_ZG96kz for ; Thu, 2 Jul 2015 02:31:57 -0700 (PDT) Received: from bin-vsp-out-04.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25DDB1B3125 for ; Thu, 2 Jul 2015 02:31:56 -0700 (PDT) X-Halon-ID: 2c7b642a-209d-11e5-b1d9-005056917c0c Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.66.32.27]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Thu, 2 Jul 2015 11:31:53 +0200 (CEST) Message-ID: <55950507.3010306@omnitor.se> Date: Thu, 02 Jul 2015 11:31:51 +0200 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: ecrit@ietf.org References: <6EB1BAFC-49FC-4D1F-92A2-E01C931FE92B@cisco.com> <8756CB1D-6CC2-405A-86E3-E89BDB607E81@gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01EF730DD21E@HE113667.emea1.cds.t-internal.com> <276B7588-3377-4900-9125-4F7729F4E530@cooperw.in> In-Reply-To: <276B7588-3377-4900-9125-4F7729F4E530@cooperw.in> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-held-routing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 09:31:59 -0000 I have seen one minor typo and have one question: 1. Typo: In 3, second line under figure 1, starts: "initiates and emergency" should be: "initiates an emergency" 2. Question: The draft only talks about routing by location information. Is there no need to consider other data involved in the routing decisions, as e.g. stated in this paragraph in RFC 6443, section 6: " Routing to the most appropriate PSAP is always based on the location of the caller, despite the fact that some emergency calls are placed on behalf of someone else, and the location of the incident is sometimes not the location of the caller. In some cases, there are other factors that enter into the choice of the PSAP that gets the call, such as time of day, caller media requests, language preference, and call load. However, location of the caller is the primary input to the routing decision." Regards If the answer on this question does not cause any major rethinking, I support publishing. Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 Alissa Cooper skrev den 2015-07-02 00:59: > The WGLC already came and went. > > I’d like to know if folks (other than the authors) have reviewed the draft and support its publication. > > Thanks, > Alissa > > On Jun 21, 2015, at 11:32 PM, R.Jesske@telekom.de wrote: > >> I support to proceed this draft to WGLC. >> >> Best Regards >> >> Roland >> >>> On 27 May 2015, at 10:05 pm, Marc Linsner (mlinsner) wrote: >>> >>> All, >>> >>> This marks the start of working group last call on this draft. Please review and send comments to the list by COB, Wednesday June 10th, 2015. >>> >>> https://tools.ietf.org/html/draft-ietf-ecrit-held-routing-02 >>> >>> Thanks, >>> >>> Marc & Roger >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Thu Jul 2 06:59:58 2015 Return-Path: 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 04BE31AC39E for ; Thu, 2 Jul 2015 06:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, 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 KkCFjIy0aylB for ; Thu, 2 Jul 2015 06:59:53 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875591A8A15 for ; Thu, 2 Jul 2015 06:59:53 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id E5BFE9C444D05; Thu, 2 Jul 2015 13:59:48 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t62DxllL015632 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Jul 2015 15:59:51 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 2 Jul 2015 15:59:48 +0200 From: "DRAGE, Keith (Keith)" To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= , "ecrit@ietf.org" Thread-Topic: [Ecrit] WGLC - draft-ietf-ecrit-held-routing Thread-Index: AQHQmHVrxR16KncLa0eKO22wA4VexJ3HcjpEgACPLYCAAGuU4A== Date: Thu, 2 Jul 2015 13:59:47 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69738934@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <6EB1BAFC-49FC-4D1F-92A2-E01C931FE92B@cisco.com> <8756CB1D-6CC2-405A-86E3-E89BDB607E81@gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01EF730DD21E@HE113667.emea1.cds.t-internal.com> <276B7588-3377-4900-9125-4F7729F4E530@cooperw.in> <55950507.3010306@omnitor.se> In-Reply-To: <55950507.3010306@omnitor.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-held-routing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 13:59:56 -0000 In regard to your question in 2). Any routeing decisions are made in the ESRP as indicated in figure 1 and 2. As far as I can tell the draft is silent on what the ESRP does as far as ro= uteing is concerned, except to make the statement: The terms LIS, ESRP, VSP and PSAP are used as defined in [RFC6443]. Which encompasses exactly the reference you have made. The draft is essentially about getting a location to the entity making the = routeing decision, not about how the routeing decision is made. Regards Keith=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of=20 > Gunnar Hellstr=F6m > Sent: 02 July 2015 10:32 > To: ecrit@ietf.org > Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-held-routing >=20 > I have seen one minor typo and have one question: >=20 > 1. Typo: > In 3, second line under figure 1, starts: > "initiates and emergency" > should be: > "initiates an emergency" >=20 > 2. Question: >=20 > The draft only talks about routing by location information. > Is there no need to consider other data involved in the=20 > routing decisions, as e.g. stated in this paragraph in RFC=20 > 6443, section 6: >=20 > " Routing to the most appropriate PSAP is always based on=20 > the location > of the caller, despite the fact that some emergency calls=20 > are placed > on behalf of someone else, and the location of the incident is > sometimes not the location of the caller. In some cases,=20 > there are > other factors that enter into the choice of the PSAP that gets the > call, such as time of day, caller media requests, language > preference, and call load. However, location of the caller is the > primary input to the routing decision." >=20 > Regards >=20 > If the answer on this question does not cause any major=20 > rethinking, I support publishing. >=20 > Gunnar >=20 >=20 > -- > ----------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 >=20 >=20 >=20 > Alissa Cooper skrev den 2015-07-02 00:59: > > The WGLC already came and went. > > > > I'd like to know if folks (other than the authors) have=20 > reviewed the draft and support its publication. > > > > Thanks, > > Alissa > > > > On Jun 21, 2015, at 11:32 PM, R.Jesske@telekom.de wrote: > > > >> I support to proceed this draft to WGLC. > >> > >> Best Regards > >> > >> Roland > >> > >>> On 27 May 2015, at 10:05 pm, Marc Linsner (mlinsner)=20 > wrote: > >>> > >>> All, > >>> > >>> This marks the start of working group last call on this=20 > draft. Please review and send comments to the list by COB,=20 > Wednesday June 10th, 2015. > >>> > >>> https://tools.ietf.org/html/draft-ietf-ecrit-held-routing-02 > >>> > >>> Thanks, > >>> > >>> Marc & Roger > >>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ecrit > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > --=20 > ----------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From nobody Thu Jul 2 14:27:55 2015 Return-Path: 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 AA5AE1A86E8 for ; Thu, 2 Jul 2015 14:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 HVaeq69o-ttA for ; Thu, 2 Jul 2015 14:27:52 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482A71A1BCD for ; Thu, 2 Jul 2015 14:27:51 -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=1435872473; x=1467408473; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=N80cvHShHOEcAnRe1ioTD7hPDgbcHsXy7Nb5/3QEgAE=; b=B+3jRHeJGeSCFpf3QZ+vMljTVtbUTXzqSxNAEV3+99qE3d64bmJvaXAS IvDKwsfkqgFPqWR2NkYY3ik8rM8d3ZMeFn7XUby+in1mlhUH0xY5bujsF LT7BTQG/qOpQec/nwZ1qfgWcENWldaLpr2GeDs/VEcDzgNEV+GumODtBC Q=; X-IronPort-AV: E=McAfee;i="5700,7163,7850"; a="91934637" Received: from unknown (HELO ironmsg02-lv.qualcomm.com) ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 02 Jul 2015 14:27:51 -0700 X-IronPort-AV: E=Sophos;i="5.15,394,1432623600"; d="scan'208";a="32910135" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 Jul 2015 14:27:50 -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; Thu, 2 Jul 2015 14:27:48 -0700 Message-ID: In-Reply-To: References: <0545a5a6cb97408c9a6a288b6831a61f@DAGN04A-S1E7.exg7.exghost.local> X-Mailer: Eudora for Mac OS X Date: Thu, 2 Jul 2015 11:06:47 -0700 To: Matt Serra , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 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: Subject: Re: [Ecrit] Suggestion for "Provider-Info" block usage (draft-ietf-ecrit-additional-data-29.txt) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 21:27:54 -0000 My apologies, version -30 omitted this change. It's been added to -31. At 3:49 PM -0700 5/5/15, Randall Gellens wrote: > At 10:05 PM +0000 5/1/15, Matt Serra wrote: > >> Our NENA Additional Data WG made an observation that we'd like to >> submit for the groups consideration: >> >> We noted section 4.1 describes the usage for the "Data Provider >> Information Block" as "SHOULD" and "MAY" provide. >> >> We'd like to propose that the group consider making the usage of >> this block "Conditional": MUST be provided if the data-provider >> inserts any other block, otherwise MAY be provided. >> >> This would ensure that the provider of all data inserted into the >> Call Info header identifies themselves. > > This seems reasonable to me: if an entity adds any blocks, it MUST > add a Provider Info block. If it touches the call in some way but > does not add any blocks, it MAY add a Provider Info block (to > indicate that it did touch the call, which might be useful for > after the fact problem tracking). > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > Americans have an abiding belief in their ability to control reality > by purely material means.... airline insurance replaces the fear of > death with the comforting prospect of cash. > ==Cecil Beaton, It Gives Me Great Pleasure, 1955. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- In the '80's my gut feeling was that airlines were crap. I hated spending time on planes. I thought we could create the kind of airline I'd like. So we got a secondhand 747 and gave it a go. --Richard Branson, founder of Virgin Atlantic. May 2006 From nobody Thu Jul 2 14:28:20 2015 Return-Path: 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 1D2881A6F07 for ; Thu, 2 Jul 2015 14:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.419 X-Spam-Level: X-Spam-Status: No, score=-5.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 j77JANJikmLu for ; Thu, 2 Jul 2015 14:28:16 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CBED1A1BCD for ; Thu, 2 Jul 2015 14:28:16 -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=1435872497; x=1467408497; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=XaGGMUFcSfl93VpOlacdhwvuyikMjwS9Hh8c0Iy9cZ0=; b=duX6jpsrKbXCDNYqMDAVBtkTntAnYpsEuXaHw2gsxmepmPohRFLYkpC2 pDWFXxzyPONFqEPMfSulcUmqLMtSajZIA/aGGu+0stTYCg1sZJC4vYjOg pBObR6Oj8y24nXsZnIAcfJZ9kDIwKSRhRMiEI+TpSOyLtB87EdNED/6z9 4=; X-IronPort-AV: E=McAfee;i="5700,7163,7850"; a="91934644" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jul 2015 14:28:17 -0700 X-IronPort-AV: E=Sophos;i="5.15,394,1432623600"; d="scan'208";a="952524894" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 Jul 2015 14:27:53 -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; Thu, 2 Jul 2015 14:27:50 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Thu, 2 Jul 2015 11:13:41 -0700 To: Matt Serra , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 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: Subject: Re: [Ecrit] Suggestion for "Provider-Info" block usage (draft-ietf-ecrit-additional-data-29.txt) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 21:28:18 -0000 As a simplification to the mechanism I described in my reply on May 5th, the categorization of a block as providing information about the call, the caller, or the location has been added to the Additional Data Blocks registry in the document as a new column. The text has been updated to clarify that, while all blocks defined in the document provide data about the call, any new blocks added to the registry in the future must be categorized. Also, I realize that in my previous reply I neglected to address Matt's statement that the unique 'purpose' value of each block was dropped. This was not dropped, it remains an integral aspect of the mechanism; the unique 'purpose' value is how entities know if they are capable of processing a block and if they wish to access the block. The changes described here were accidently omitted from version -30 but have been added to -31. At 4:00 PM -0700 5/5/15, Randall Gellens wrote: > At 10:21 PM +0000 5/1/15, Matt Serra wrote: > >> Another recommendation coming out of the NENA Additional Data WG: >> >> I raised this a few weeks ago, and I realize I may not have been >> clear enough the first time around. After speaking with Randall >> Gellens this evening, he recommended I resubmit this suggestion >> for re-consideration by this work group: >> >> The Additional Data Draft, as written, describes mechanisms to >> carry additional information about the call itself. >> >> The mechanisms defined in this additional-data document are >> targeted for expansion. This is alluded to in section 1, where it >> recognizes the existence of data that can be associated with a >> Caller and Location in addition to the Call. >> >> Since it is likely that additional data blocks will be added to >> address Caller and Location, and that Caller and Location data may >> reuse some of the data-blocks identified for Call Data (minimally >> Provider Information and Comments) an additional field, named >> something like "Information About", with an initial registry value >> of "Call" may be warranted. This could be expanded to include >> "Location", "Caller", etc. as Data Structures are added to the >> Emergency Call Data Types registry (10.1.10) to support other >> forms of data. >> >> Potentially this new field could be located in the Provider Info >> block, although Randy suggested it is probably best in each of the >> other blocks defined in this draft standard. This would allow any >> system processing the Call Info headers to readily determine what >> "kind" of data is being conveyed. >> >> At one time, forms of Additional Data were to be distinguished >> with a unique Purpose Parameter, but that was abandoned somewhere >> during the development of i3 or this IETF spec - likely for good >> reason. If valid, that would be another approach. >> >> I hope I'm being more clear this time around! > > I'd like to suggest that this additional information exist in the > registration information for each block, but not in the block > itself. > > Currently, the registration/description of each block carries the > following items of information (referred to as labels): > > Data Element: A unique human-readable concise name for the block > Use: Required, Conditional, or Optional > XML Element: a unique XML element name > Description: Human-readable description of the block > Reason for Need: Human-readable explanation of why the block is needed > How Used by Call Taker: Human-readable explanation of how block is used > > I'm suggesting that we add one additional item to this list: > Information About. > > This would not change the contents of the blocks (and hence nor > their XML schema), it only changes the description of the blocks. > However, this should make it easier for entities to establish > policy as to which blocks they will access and which they won't. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > Progress is made on alternate Fridays. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Why is it that we rejoice at a birth and grieve at a funeral? It is because we are not the person involved. --Mark Twain From nobody Thu Jul 2 14:44:51 2015 Return-Path: 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 1EE491A8740 for ; Thu, 2 Jul 2015 14:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.388 X-Spam-Level: X-Spam-Status: No, score=-4.388 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 NptKQh36Nn4g for ; Thu, 2 Jul 2015 14:44:47 -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 A4AA61A903A for ; Thu, 2 Jul 2015 14:43:25 -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=1435873406; x=1467409406; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=+U7DoGiw7ni+NZYyC2wDSee3lalnI6G8mfAtNVG3D+I=; b=yb+Ie+ASpIoX/FtFpCxIpjNsxlv+RYGbzgzdx+Lgtd//L6lCAA0cOJ3s lK0aZWPxMlUNSi51+f4tXcRys0mnioE/v6wcV6TkKUAtxyEjRDtFMfGVV Vkt8ddJuv4U0oXxXsUFNCmpzkpoB240XQ6SqOLA3hTYXi3iKAxipMa/1L I=; X-IronPort-AV: E=McAfee;i="5700,7163,7850"; a="92991877" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jul 2015 14:43:25 -0700 X-IronPort-AV: E=Sophos;i="5.15,395,1432623600"; d="png'150?scan'150,208,217,150";a="925928918" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 Jul 2015 14:43:25 -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; Thu, 2 Jul 2015 14:43:23 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Thu, 2 Jul 2015 14:43:20 -0700 To: Matt Serra , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: multipart/related; boundary="============_-776249091==_mr============"; type="text/html" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Subject: Re: [Ecrit] Request for clarification: Dave Provider ID / Data Provider ID Series Usage (and Type of Data Provider) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 21:44:50 -0000 --============_-776249091==_mr============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] Request for clarification: Dave Provider ID /
Hi Matt,

My apologies for not replying to this sooner, I intended to do so when I made the other changes to -30.

The changes to -30 make it clear that the device fills in the Data Provider block using 'device' as type of provider, and omits the Provider ID and Provider ID Series.

At 10:41 PM +0000 5/26/15, Matt Serra wrote:

Content-Language: en-US
Content-Type: multipart/related;
 boundary=3D"_004_ed375d4434db4875baa41a892df4019dDAGN04AS1E7exg7exghostl_";
 type=3D"multipart/alternative"
I have not seen any comment on this, so I'll try to bring the issue into sharper focus.
 
I'd appreciate knowing if there is support for the Preferred Solution or Alternate Solution I outline below (or if you have better idea).
 
Problem:
=B7         Within the Data Provider Block, Data Provider ID and Provider ID Series are required fields.
=B7         Per the DRAFT, there are cases where an entity providing the Data Provider Block would not be able to fill out these required fields as they are defined, which in North America calls for populating a NENA Company ID which an end-user would not have.
=B7         Examples of entities that could not meet this requirement are end-user managed devices or a user agent used to place an emergency call.
 
Preferred Solution:
=B7         Instruct the Device or User Agent to populate Data Provider ID with the PAI or From URI from the SIP INVITE
=B7         Instruct the Device or User Agent to populate Data Provider ID Series with 'End-User' or a similar string.  Update the Provider ID registry with this new value
=B7         Add a value to the Type of Data Provider to read as "End User" "User Agent" or similar
 
Alternate Solution:
=B7         Make the Data Provider ID and Provider ID Series Conditional (optional where provided by end-user device or user agent, otherwise required)
=B7         Add a value to the Type of Data Provider to read as "End User" "User Agent" or similar to provide some context to the reader of the XML document.
 
Thanks,
 
Matt.
 
From: Matt Serra
Sent: Monday, May 11, 2015 11:24 AM
To: ecrit@ietf.org
Subject: Request for clarification: Dave Provider ID / Data Provider ID Series Usage (and Type of Data Provider)
 
Group:
 
In the Additional Call Data draft, the Data Provider ID and Data Provider ID Series fields within the Data Provider Information Block are shown as Required.
 
In addition to coming from a Service or Access provider, the Additional Call Data can also be provided by the device or user agent.
 
In the case of the Device or User Agent, how should these blocks be populated?  The device or UA would not have a NENA or EENA assigned Data Provider ID.  While the spec allow for a "domain" to be used as a Provider ID, the domain alone would not uniquely identify the device or User agent.  That language seems to exist to accommodate Service and Access Network providers.
 
So - it seems like we should EITHER provide guidance on how to populate these fields in this case (perhaps populate the Data Provider ID with From URI or PAI? And Data Provider ID Series with "domain" or maybe "URI"?!?!)  OR make these fields optional where provided by a device or user agent and allow the From URI/PAI in the INVITE to speak for themselves?
 
This also has ramifications on "Type of Data Provider" as well.  There should be "Device" and "User Agent" value(s) I'd think.
 
Thanks,
 
3D"image001
  Matthew A. Serra, ENP
  Sr. Director, Product Management
  Mobile:  201.245.1557
  mserra@ravemobilesafety.com
 
 

Content-Type: image/png; name=3D"image001.png"
Content-Description: image001.png
Content-Disposition: inline; filename=3D"image001.png"; size=3D3039;
   creation-date=3D"Tue, 26 May 2015 22:41:20 GMT";
  modification-date=3D"Tue, 26 May 2015 22:41:20 GMT"
Content-ID: <image001.png@01D097E2.B5B38AB0>

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit



--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
One might say that the right's approach is to release the dogs of the
market, throwing all traditional values into disarray; and then, in
this tumult of insecurity, offer themselves up as the last bastion of
order and hierarchy, the stalwart defenders of the authority of
churches and fathers against the barbarians they have themselves
unleashed.  A scam it may be, but it is a remarkably effective one;
and one result is that the right ends up seeming to have a monopoly on
value.  --David Graeber, "Army of Altruists", Harper's, January 2007.
--============_-776249091==_mr============ Content-ID: Content-Type: image/png; name="image001 66.png"; x-mac-type=504E4766; x-mac-creator=C74943C8 Content-Disposition: attachment; filename="image001 66.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAKoAAAA4CAYAAABt2GPKAAAAGXRFWHRTb2Z0d2FyZQBB ZG9iZSBJbWFnZVJlYWR5ccllPAAAAyJpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/ eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+ IDx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2Jl IFhNUCBDb3JlIDUuMC1jMDYwIDYxLjEzNDc3NywgMjAxMC8wMi8xMi0xNzozMjowMCAg ICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5 LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9 IiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bWxuczp4 bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHht cDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHhtcE1N Okluc3RhbmNlSUQ9InhtcC5paWQ6RTRDQ0FBRDE4ODI2MTFFMzkwNzRCNERGRkY0MDc3 Q0YiIHhtcE1NOkRvY3VtZW50SUQ9InhtcC5kaWQ6RTRDQ0FBRDI4ODI2MTFFMzkwNzRC NERGRkY0MDc3Q0YiPiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0i eG1wLmlpZDpFNENDQUFDRjg4MjYxMUUzOTA3NEI0REZGRjQwNzdDRiIgc3RSZWY6ZG9j dW1lbnRJRD0ieG1wLmRpZDpFNENDQUFEMDg4MjYxMUUzOTA3NEI0REZGRjQwNzdDRiIv PiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFj a2V0IGVuZD0iciI/PlzaqucAAAhTSURBVHja7F1bbttGFB0H+Y8W0ALsd9HGXoGlFVj+ LVqIXoGsFchegaUVmAKK/kZZgekVhEXRb7NA/6uuwJ3r3gkmjETeMxyKD88FFCUK533m 3MfckU6en59VkCBdl7f0x7c//tIGWnf6lenXo35t//7j1+yYjX/zw88j/fakXyNhkVT3 cSKo91S/fQK68p2uN/c8tgf9NhY+nuj2r6yyVO6hYzidvGmx8RFP5pIWVk/Qk35dM4CO IdcASEnGvIilwhsuBeqNPYM0AkBKsu4Do77pUF9ogu8YtOMmG+LNMHcouhQ+twHqnHse 3hJ4Nj22JhsCUG3APmgwxQ22gbIpyqqJfpOq85GvsfIGnA6NTbsKVCP3TYC1Bps2yaoz T8OLgQ2Y6w21DUD1B9bTjrApxKpaVmCdPsaJbMDesOlnrx+QHGQKW85BI98I2a0TH4P1 wKY2q6YV6n+n20sAZ4n6dVVjbFM2myRCEZdk0EDVC3BTEyjXoMFPbBN5CuHUZdMvWFX3 qcq7XwNAneo6FwRwxz4h5kNSox1bbuvgobOqnyaHB3YJFp3Wbdsjm4ptVfaopV71SDmG qjgkNUgnqlUblY34FCjigwWlbCoFltRWRUDhupGQclvfBwxDd6Yej9UQyKYLWkyPrJqw TSiRiG1NdGwIE/eOTfvg9R/b00/Z7pQuZhOsioaqpoDGyQR2dQBqDXE+PQHZdM0smAJt ShxDxMOess3ZhNrvJZu2DdQL4Nk6LCBl02IA3Bursk2Y+AYftyuNv+7YDOmlvG2jUT5x kk6wcygFZNPbom2pyxNbSthtJthMG8CWjNlW9mkmNMGm53qObhqESmIcv7dHBigaR90V AdQgmyYHFvdOAiw9ttsyb5rMCf1MJtygL+f/ZQzI5gHiRK0aWNKxcjvEQTSpE1Ajxx30 jhcIHdSVayilDpsWbMulEOz0XNXJEgH/HlD/SQXrIsy0Uz0WGKgKO1VyFQLnZc0UNCmb 0gJuD7AgHYOuhWOWsCqZE3fCfp3S+X/JHLwKJ6qrXr9R9Wd1QIp6+hVsgzggS8+gmZfY +MjNhCwA1Z9kDNAbD2oKYdOVR489FoSWEODHB248tO1EvWqgkg1L11HuwThiHTaV2m6I Q7f0CPyvbFFOB5Ta+r3KOfVpox5DaGEo6D1xVFlIhpSIbQhcuj+pECCVtqrCQlXzAut3 yTZNlHvap1TLOgE1Bzv2nkETKXmupOIydB3lDPH6QTbNGVSI/Yyw6lUJ8ClUlQvn5OX8 n5gRPNc/Rs7pX8c6kj1aPiqrrDkw0SMO5SBJ0wibNhnBkLDqrZKHqmYcmYiBPvQ+JNWK jUpqnO+PI1ns4isaDeSb1pWqTbAFWNqc/7+qkFSrzhSftiAqSZr25it73yerRiXzgKrm D4D51Muc0y56/YgXfd5DNpWyKsJ6yOW/QbFpa0Dl3S716CUs0jU2lbJqruRJ2ogfkQ4N qG2Gp6QJGpFHNt2pGrmtBUdPynBVOQBr5eFOmKO2CkCVhDY81YOw6cJHTiZvjn98RADA UFXlRuxzzmlXgZqqmuEhNG7qaxEd7+wvKljw3kPXjm2bLjlnt3Gs9OIqSkkGPcKmvk9Q EBUbV3xLIRKqKpNBsmmbXr+qa/A72KYrz/3PlfyKjEkYP8jQHkCWDC0k1QmggjKuyabr hk5pEFadV7BqXbW9VgOWtoEq9cDf12DTxlQieFu1ilVz5R6qGkTOaZeBKlWdxSvECJs2 rRKhROiGWHWjBi5tAxWZ4PuCF92EenZhVWJr6UaoYtUUqMt7NKPTEn4VJUhg1CBBPMlL wP/fn74fh6kI0nmgqu79rlCQIHuBOglTESQ4U0GCBGcqyGtypoyNevvutz9T85/6c4pd Rvq10Z8nZRXpZ02M0GTk51xfXtUJq31lld3YfTlQLlb/X3xb6Gezquf0M2ITR5ehfNN9 X5BWORdAGzfWfO14vjJhWZrri+KaOYynau72+i9lc3mojJZMl1tUzMXn8ejPCHuEwcww 6phfM6sgPRTz55Fg7qhzSwYZDZySgT/xBFVJsQ0q+8B9KJOIy46EzyEyEtZdB6QmRS7j tiRjNrIsrllD46Eyrr+BFQFtJtyOfbBzx+U/FvNRCSAmGz0GJj3mRmh3rvgzOnX6xBMq +RUUYqobqz7D5rlqVxYSxnKQc5uZ9JjpNw0+SMasnzVfh079ivW/qY+7BseTIdrIGpPZ jJVtkubVz798IR2XSxmPCZW1gUoJEVMCCau2GU+YZIdfcGMrq+FM12UaEy0cd9DU5+va SF2ZFeLMicScEQgBc6zrfuK5f9T1nkj7xGuzYDKgjb1yGE8uNGMia21I0iY2LxGVbofW fm5hYGGHp0h+Z1a80A9nDNCVKjmbLqiVvTsRULnRnr9HHQBrUbOkPlieF2XHC0JzfM3/ PivbCGwa0OZfMRnk6uuv/ZGOJ1WyzLJIfX0bI21ovhdsRhIWr4ymKKr+DXdox6+PQqDm ZhILkzxW8sx1W/WbO0m1fnbRk0yaYA+j3kgL8Xhjtsno/UYAtGt2qEx9Y2E/XcaTIqq/ 5gZOWROPbbZ/s8egNZOBeLYmC+qOJ922W11S107V8IU24T1vbsTMmfGzE35dWp8POzxV MGjNNeaN1EPkXXDLbDxlFWaMfalKIiPaVi875TlrXdf/XOi3xCYkT7wJdlmww/hkzVfp lRR2oqKic8JrNgWdKsjzd5w770CdWHYX7dCI7Z9R4f+qbK6t5TyRpyjNWJ/sA78wpJEK 2ChxsKkytf9o2QsQSK1ZzuaI53hbATTTp+J4LwVO76Gy8NoAIl2ffZv4C5I8CUeoQfog 4Qg1SC/kPwEGAAO+sOGPE+6YAAAAAElFTkSuQmCC --============_-776249091==_mr============-- From nobody Thu Jul 2 14:45:43 2015 Return-Path: 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 EB9221A8930 for ; Thu, 2 Jul 2015 14:45:41 -0700 (PDT) X-Quarantine-ID: <3SCIzdhnOvK6> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 3SCIzdhnOvK6 for ; Thu, 2 Jul 2015 14:45:40 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E4F1A8BBD for ; Thu, 2 Jul 2015 14:44:03 -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=1435873443; x=1467409443; h=message-id:in-reply-to:references:date:to:from:subject: content-transfer-encoding; bh=/7VZfIG8AMz96FzKfPabQ0mYwKbEGg1DQmLT+sSRA5c=; b=mmKNq88ddfCKtHDbrIAoorwzwrWq1syi78D/Wve1MNUxekxTkoVlbovt fJqtXsQ+puSXg7s/+Jat20uUhWA/57f3rTEeqG364QeGjDmDsn7hDsIjx O8z724p7l04yQhMyfXkbWfGmFVEOr129zRo6O6gHMYnOOiAwGJouYcptI g=; X-IronPort-AV: E=McAfee;i="5700,7163,7850"; a="218618103" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jul 2015 14:43:44 -0700 X-IronPort-AV: E=Sophos;i="5.15,395,1432623600"; d="scan'208";a="950896894" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jul 2015 14:43:44 -0700 Received: from Ironmsg03-R.qualcomm.com (ironmsg03-R.qualcomm.com [172.30.46.17]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t62Lhhuv006214; Thu, 2 Jul 2015 14:43:44 -0700 X-IronPort-AV: E=Sophos;i="5.15,395,1432623600"; d="scan'208";a="952533111" X-ojodefuego: yes Received: from unknown (HELO [65.122.198.41]) ([10.64.194.154]) by Ironmsg03-R.qualcomm.com with ESMTP; 02 Jul 2015 14:43:43 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Thu, 2 Jul 2015 14:43:39 -0700 To: Matt Serra , "ecrit@ietf.org" From: Randall Gellens 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-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Ecrit] Request for clarification: Dave Provider ID / Data Provider ID Series Usage (and Type of Data Provider) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 21:45:42 -0000 Hi Matt, My apologies for not replying to this sooner, I=20 intended to do so when I made the other changes=20 to -30. The changes to -30 make it clear that the device=20 fills in the Data Provider block using 'device'=20 as type of provider, and omits the Provider ID=20 and Provider ID Series. At 10:41 PM +0000 5/26/15, Matt Serra wrote: > Content-Language: en-US > Content-Type: multipart/related; > boundary=3D"_004_ed375d4434db4875baa41a892df4019dDAGN04AS1E7exg7exghostl= _"; > type=3D"multipart/alternative" > > I have not seen any comment on this, so I'll=20 > try to bring the issue into sharper focus. > > I'd appreciate knowing if there is support for=20 > the Preferred Solution or Alternate Solution I=20 > outline below (or if you have better idea). > > Problem: > =B7 Within the Data Provider Block, Data=20 > Provider ID and Provider ID Series are required=20 > fields. > =B7 Per the DRAFT, there are cases where=20 > an entity providing the Data Provider Block=20 > would not be able to fill out these required=20 > fields as they are defined, which in North=20 > America calls for populating a NENA Company ID=20 > which an end-user would not have. > =B7 Examples of entities that could not=20 > meet this requirement are end-user managed=20 > devices or a user agent used to place an=20 > emergency call. > > Preferred Solution: > =B7 Instruct the Device or User Agent to=20 > populate Data Provider ID with the PAI or From=20 > URI from the SIP INVITE > =B7 Instruct the Device or User Agent to=20 > populate Data Provider ID Series with=20 > 'End-User' or a similar string. Update the=20 > Provider ID registry with this new value > =B7 Add a value to the Type of Data=20 > Provider to read as "End User" "User Agent" or=20 > similar > > Alternate Solution: > =B7 Make the Data Provider ID and=20 > Provider ID Series Conditional (optional where=20 > provided by end-user device or user agent,=20 > otherwise required) > =B7 Add a value to the Type of Data=20 > Provider to read as "End User" "User Agent" or=20 > similar to provide some context to the reader=20 > of the XML document. > > Thanks, > > Matt. > > From: Matt Serra > Sent: Monday, May 11, 2015 11:24 AM > To: ecrit@ietf.org > Subject: Request for clarification: Dave=20 > Provider ID / Data Provider ID Series Usage=20 > (and Type of Data Provider) > > Group: > > In the Additional Call Data draft, the Data=20 > Provider ID and Data Provider ID Series fields=20 > within the Data Provider Information Block are=20 > shown as Required. > > In addition to coming from a Service or Access=20 > provider, the Additional Call Data can also be=20 > provided by the device or user agent. > > In the case of the Device or User Agent, how=20 > should these blocks be populated? The device=20 > or UA would not have a NENA or EENA assigned=20 > Data Provider ID. While the spec allow for a=20 > "domain" to be used as a Provider ID, the=20 > domain alone would not uniquely identify the=20 > device or User agent. That language seems to=20 > exist to accommodate Service and Access Network=20 > providers. > > So - it seems like we should EITHER provide=20 > guidance on how to populate these fields in=20 > this case (perhaps populate the Data Provider=20 > ID with From URI or PAI? And Data Provider ID=20 > Series with "domain" or maybe "URI"?!?!) OR=20 > make these fields optional where provided by a=20 > device or user agent and allow the From URI/PAI=20 > in the INVITE to speak for themselves? > > This also has ramifications on "Type of Data=20 > Provider" as well. There should be "Device"=20 > and "User Agent" value(s) I'd think. > > Thanks, > > > Matthew A. Serra, ENP > Sr. Director, Product Management > Mobile: 201.245.1557 > mserra@ravemobilesafety.com > > > > Content-Type: image/png; name=3D"image001.png" > Content-Description: image001.png > Content-Disposition: inline; filename=3D"image001.png"; size=3D3039; > creation-date=3D"Tue, 26 May 2015 22:41:20 GMT"; > modification-date=3D"Tue, 26 May 2015 22:41:20 GMT" > Content-ID: > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Computers are useless. They can only give you answers. --Pablo Picasso (1881-1973) From nobody Fri Jul 3 00:14:03 2015 Return-Path: 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 EEF821B2E27 for ; Fri, 3 Jul 2015 00:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no 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 BLKLehAmR2m7 for ; Fri, 3 Jul 2015 00:13:59 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877E71B2E23 for ; Fri, 3 Jul 2015 00:13:59 -0700 (PDT) Received: by oiaf66 with SMTP id f66so40879714oia.3 for ; Fri, 03 Jul 2015 00:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YYrtCChoV09yCZVwn+3XWNJ3Orhx7H10bVqru3b3E5k=; b=UciHZHHnVsk67Qc8OCU+p7+88GgpWFnV+9tlFYYGe2sJKLLiNYCZhfRRnUyOyrd8gH fKC+uCjJ6VysVCRbbH0WBGO8+Skd9mxbTD3YqnQjCc5npaNrgEEuXyVoMNw1Klx6lQ34 P5/eMUzrj8ddJIlhBgPtTTlqhtW+M+/lHzpvOMUqrukdunEqM1vcXruRQ1uBIvW8R4rz 9FjqOpi1m5bA495RDAkn/XTKhYYy5uT5lJK8bx45sQPaIJHmZ0Oq0OzPVvmU1GuCVD5q JMbBhWaTxKVRDCqLoPFJVzOdaYCPl9J20LbKN/+IJ8sGTSjvzWb6X1HNvwFoWc4Omrh4 CcBQ== MIME-Version: 1.0 X-Received: by 10.202.57.137 with SMTP id g131mr30230338oia.122.1435907639058; Fri, 03 Jul 2015 00:13:59 -0700 (PDT) Received: by 10.76.81.38 with HTTP; Fri, 3 Jul 2015 00:13:58 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69738934@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <6EB1BAFC-49FC-4D1F-92A2-E01C931FE92B@cisco.com> <8756CB1D-6CC2-405A-86E3-E89BDB607E81@gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01EF730DD21E@HE113667.emea1.cds.t-internal.com> <276B7588-3377-4900-9125-4F7729F4E530@cooperw.in> <55950507.3010306@omnitor.se> <949EF20990823C4C85C18D59AA11AD8B69738934@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Fri, 3 Jul 2015 09:13:58 +0200 Message-ID: From: Laura Liess To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Content-Type: multipart/alternative; boundary=001a113cee2ac1aa1d0519f34cf5 Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-held-routing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 07:14:02 -0000 --001a113cee2ac1aa1d0519f34cf5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gunnar, Keith is right. The draft is intended to enable the LIS to provide the SIP-URI of an Emergency Calling Routing Proxy (ESRP) trusted by the LIS, which is able to dereference the LbyR sent in the emergency call and then route the emergency call to the correct. PSAP. We can not expect the LIS of every small access network provider to have deep knowledge about the PSAP-infrastructure, we expect the ESRP to have it or to be able to get it. The ESRP is also able to analyse the emergency call, find out, e.g., if the caller would prefer text to audio and route it to the apropriate PSAP. I think in some countries (UK ?) they have one central PSAP which gets all emergency calls and then route them to the appropriate local PSAP. (This why we have ESRP/PSAP and "routing to the appropriate PSAP in the draft.) There is no need to consider other factors such as time of day, caller media requests, language preference, and call load to be considered at then interface between the Softswithch and the LIS, these factors have to be considered by the ESRP when it chooses the final destination (PSAP) for the emergency call. Thank you Laura 2015-07-02 15:59 GMT+02:00 DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com>: > In regard to your question in 2). > > Any routeing decisions are made in the ESRP as indicated in figure 1 and = 2. > > As far as I can tell the draft is silent on what the ESRP does as far as > routeing is concerned, except to make the statement: > > The terms LIS, ESRP, VSP and PSAP are used as defined in [RFC6443]. > > Which encompasses exactly the reference you have made. > > The draft is essentially about getting a location to the entity making th= e > routeing decision, not about how the routeing decision is made. > > Regards > > Keith > > > -----Original Message----- > > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of > > Gunnar Hellstr=C3=B6m > > Sent: 02 July 2015 10:32 > > To: ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-held-routing > > > > I have seen one minor typo and have one question: > > > > 1. Typo: > > In 3, second line under figure 1, starts: > > "initiates and emergency" > > should be: > > "initiates an emergency" > > > > 2. Question: > > > > The draft only talks about routing by location information. > > Is there no need to consider other data involved in the > > routing decisions, as e.g. stated in this paragraph in RFC > > 6443, section 6: > > > > " Routing to the most appropriate PSAP is always based on > > the location > > of the caller, despite the fact that some emergency calls > > are placed > > on behalf of someone else, and the location of the incident is > > sometimes not the location of the caller. In some cases, > > there are > > other factors that enter into the choice of the PSAP that gets the > > call, such as time of day, caller media requests, language > > preference, and call load. However, location of the caller is the > > primary input to the routing decision." > > > > Regards > > > > If the answer on this question does not cause any major > > rethinking, I support publishing. > > > > Gunnar > > > > > > -- > > ----------------------------------------- > > Gunnar Hellstr=C3=B6m > > Omnitor > > gunnar.hellstrom@omnitor.se > > +46 708 204 288 > > > > > > > > Alissa Cooper skrev den 2015-07-02 00:59: > > > The WGLC already came and went. > > > > > > I'd like to know if folks (other than the authors) have > > reviewed the draft and support its publication. > > > > > > Thanks, > > > Alissa > > > > > > On Jun 21, 2015, at 11:32 PM, R.Jesske@telekom.de wrote: > > > > > >> I support to proceed this draft to WGLC. > > >> > > >> Best Regards > > >> > > >> Roland > > >> > > >>> On 27 May 2015, at 10:05 pm, Marc Linsner (mlinsner) > > wrote: > > >>> > > >>> All, > > >>> > > >>> This marks the start of working group last call on this > > draft. Please review and send comments to the list by COB, > > Wednesday June 10th, 2015. > > >>> > > >>> https://tools.ietf.org/html/draft-ietf-ecrit-held-routing-02 > > >>> > > >>> Thanks, > > >>> > > >>> Marc & Roger > > >>> > > >>> > > >>> _______________________________________________ > > >>> Ecrit mailing list > > >>> Ecrit@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/ecrit > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ecrit > > >> > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > -- > > ----------------------------------------- > > Gunnar Hellstr=C3=B6m > > Omnitor > > gunnar.hellstrom@omnitor.se > > +46 708 204 288 > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > --001a113cee2ac1aa1d0519f34cf5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gunnar,

Keith is right. The d= raft is intended to enable the LIS to provide the SIP-URI of an Emergency Calling Routing Proxy (ESRP)=20 trusted by the LIS, which is able to dereference the LbyR sent in the=20 emergency call and then route the emergency call to the correct. PSAP.=20 We can not expect the LIS of every small access network provider to have deep knowledge about the PSAP-infrastructure, we expect the ESRP to=20 have it or to be able to get it.=C2=A0 The=C2=A0 ESRP is also able to analy= se the=20 emergency call, find out, e.g.,=C2=A0 if the caller would prefer text to=20 audio and route it to the apropriate PSAP.=C2=A0 I think in some countries= =20 (UK ?)=C2=A0 they have one central PSAP which gets all emergency calls and= =20 then route them to the appropriate local PSAP. (This why we have=20 ESRP/PSAP and "routing to the appropriate PSAP in the draft.)
Ther= e is no need to consider other factors such as time of day, caller media=20 requests, language=C2=A0 preference, and call load to be considered at then= =20 interface between the Softswithch and the LIS, these factors have to be=20 considered by the ESRP when it chooses the final destination (PSAP) for=20 the emergency call.=C2=A0 =C2=A0

Thank you
Laura
=

2015-07-02 = 15:59 GMT+02:00 DRAGE, Keith (Keith) <keith.drage@alcatel-luc= ent.com>:
In regard to your= question in 2).

Any routeing decisions are made in the ESRP as indicated in figure 1 and 2.=

As far as I can tell the draft is silent on what the ESRP does as far as ro= uteing is concerned, except to make the statement:

=C2=A0 =C2=A0The terms LIS, ESRP, VSP and PSAP are used as defined in [RFC6= 443].

Which encompasses exactly the reference you have made.

The draft is essentially about getting a location to the entity making the = routeing decision, not about how the routeing decision is made.

Regards

Keith

> -----Original Message-----
> From: Ecrit [mailto:ecrit-bo= unces@ietf.org] On Behalf Of
> Gunnar Hellstr=C3=B6m
> Sent: 02 July 2015 10:32
> To: ecrit@ietf.org
> Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-held-routing
>
> I have seen one minor typo and have one question:
>
> 1. Typo:
> In 3, second line under figure 1, starts:
> "initiates and emergency"
> should be:
> "initiates an emergency"
>
> 2. Question:
>
> The draft only talks about routing by location information.
> Is there no need to consider other data involved in the
> routing decisions, as e.g. stated in this paragraph in RFC
> 6443, section 6:
>
> "=C2=A0 Routing to the most appropriate PSAP is always based on > the location
>=C2=A0 =C2=A0 =C2=A0of the caller, despite the fact that some emergency= calls
> are placed
>=C2=A0 =C2=A0 =C2=A0on behalf of someone else, and the location of the = incident is
>=C2=A0 =C2=A0 =C2=A0sometimes not the location of the caller.=C2=A0 In = some cases,
> there are
>=C2=A0 =C2=A0 =C2=A0other factors that enter into the choice of the PSA= P that gets the
>=C2=A0 =C2=A0 =C2=A0call, such as time of day, caller media requests, l= anguage
>=C2=A0 =C2=A0 =C2=A0preference, and call load.=C2=A0 However, location = of the caller is the
>=C2=A0 =C2=A0 =C2=A0primary input to the routing decision."
>
> Regards
>
> If the answer on this question does not cause any major
> rethinking, I support publishing.
>
> Gunnar
>
>
> --
> -----------------------------------------
> Gunnar Hellstr=C3=B6m
> Omnitor
> gunnar.hellstrom@omnito= r.se
> +46 708= 204 288
>
>
>
> Alissa Cooper skrev den 2015-07-02 00:59:
> > The WGLC already came and went.
> >
> > I'd like to know if folks (other than the authors) have
> reviewed the draft and support its publication.
> >
> > Thanks,
> > Alissa
> >
> > On Jun 21, 2015, at 11:32 PM, R.Jesske@telekom.de wrote:
> >
> >> I support to proceed this draft to WGLC.
> >>
> >> Best Regards
> >>
> >> Roland
> >>
> >>> On 27 May 2015, at 10:05 pm, Marc Linsner (mlinsner)
> <mlinsner@cisco.com> w= rote:
> >>>
> >>> All,
> >>>
> >>> This marks the start of working group last call on this > draft.=C2=A0 Please review and send comments to the list by COB,
> Wednesday June 10th, 2015.
> >>>
> >>> https://tools.ietf.org= /html/draft-ietf-ecrit-held-routing-02
> >>>
> >>> Thanks,
> >>>
> >>> Marc & Roger
> >>>
> >>>
> >>> _______________________________________________
> >>> Ecrit mailing list
> >>> Ecrit@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/e= crit
> >> _______________________________________________
> >> Ecrit mailing list
> >> Ecrit@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ecr= it
> >>
> >> _______________________________________________
> >> Ecrit mailing list
> >> Ecrit@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ecr= it
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit@ietf.org
> > https://www.ietf.org/mailman/listinfo/ecrit=
>
> --
> -----------------------------------------
> Gunnar Hellstr=C3=B6m
> Omnitor
> gunnar.hellstrom@omnito= r.se
> +46 708= 204 288
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

--001a113cee2ac1aa1d0519f34cf5-- From nobody Sat Jul 4 08:18:41 2015 Return-Path: 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 8D2A11AD16B; Sat, 4 Jul 2015 08:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 6u7wIyPA2MNx; Sat, 4 Jul 2015 08:18:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 660D21AD0D6; Sat, 4 Jul 2015 08:18:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150704151837.21914.27685.idtracker@ietfa.amsl.com> Date: Sat, 04 Jul 2015 08:18:37 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-31.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 15:18:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Additional Data Related to an Emergency Call Authors : Randall Gellens Brian Rosen Hannes Tschofenig Roger Marshall James Winterbottom Filename : draft-ietf-ecrit-additional-data-31.txt Pages : 110 Date : 2015-07-04 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller or the location which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry the information described here using the mechanisms described here. The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-additional-data-31 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-31 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 5 22:47:29 2015 Return-Path: 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 6426B1A87D9; Sun, 5 Jul 2015 22:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 nfvMWw7N8Ghn; Sun, 5 Jul 2015 22:47:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 162161A87B3; Sun, 5 Jul 2015 22:47:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706054726.16271.85157.idtracker@ietfa.amsl.com> Date: Sun, 05 Jul 2015 22:47:26 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-32.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 05:47:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Additional Data Related to an Emergency Call Authors : Randall Gellens Brian Rosen Hannes Tschofenig Roger Marshall James Winterbottom Filename : draft-ietf-ecrit-additional-data-32.txt Pages : 110 Date : 2015-07-05 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller or the location which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry the information described here using the mechanisms described here. The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-additional-data-32 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-32 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 5 22:52:27 2015 Return-Path: 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 B06A51A87C7 for ; Sun, 5 Jul 2015 22:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 scU-xIu_473b for ; Sun, 5 Jul 2015 22:52:24 -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 36F5C1A87CB for ; Sun, 5 Jul 2015 22:52:23 -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=1436161945; x=1467697945; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=8NFywZJaLcCIUJlFFa62Y9h+UkTE4Q0neqKMQ3Irol0=; b=xt6WLrytkxNJoXvO4ezrDnN4T3fpxxByQnDGvojQ6gpShvEeN812kzBb tjiYmQwzsHgq9Yadk8DiqNdzuzZ7p4gMSdBMemcEplWyuEPNa2Qjb64W/ FA3V1TomJshKGHaFvFl76KVYrCaDleiBh8SbSiZibUctlSXWaPWP2YI47 E=; X-IronPort-AV: E=McAfee;i="5700,7163,7853"; a="93157397" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 05 Jul 2015 22:52:23 -0700 X-IronPort-AV: E=Sophos;i="5.15,413,1432623600"; d="scan'208";a="32922085" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 Jul 2015 22:52:22 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sun, 5 Jul 2015 22:52:21 -0700 Message-ID: In-Reply-To: <20150706054726.16271.85157.idtracker@ietfa.amsl.com> References: <20150706054726.16271.85157.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Sun, 5 Jul 2015 22:52:19 -0700 To: From: Randall Gellens CC: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Subject: [Ecrit] Status of draft-ietf-ecrit-additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 05:52:26 -0000 I wanted to let everyone know that version -30 addressed all of Alissa's and Keith's comments, version -32 addressed the remaining issues identified by Matt, and version -33 fixed a potentially ambiguous sentence I noticed. So, -33 is version that is ready for last call. At 10:47 PM -0700 7/5/15, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Emergency Context Resolution with > Internet Technologies Working Group of the IETF. > > Title : Additional Data Related to an Emergency Call > Authors : Randall Gellens > Brian Rosen > Hannes Tschofenig > Roger Marshall > James Winterbottom > Filename : draft-ietf-ecrit-additional-data-32.txt > Pages : 110 > Date : 2015-07-05 > > Abstract: > When an emergency call is sent to a Public Safety Answering Point > (PSAP), the originating device, the access network provider to which > the device is connected, and all service providers in the path of the > call have information about the call, the caller or the location > which is helpful for the PSAP to have in handling the emergency. > This document describes data structures and mechanisms to convey such > data to the PSAP. The intent is that every emergency call carry the > information described here using the mechanisms described here. > > The mechanisms permit the data to be conveyed by reference (as an > external resource) or by value (within the body of a SIP message or a > location object). This follows the tradition of prior emergency > services standardization work where data can be conveyed by value > within the call signaling (i.e., in the body of the SIP message) or > by reference. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ecrit-additional-data-32 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-32 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Hollywood is where if you don't have happiness you send out for it. --Rex Reed From nobody Mon Jul 6 00:16:51 2015 Return-Path: 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 22E871A8A52 for ; Mon, 6 Jul 2015 00:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 kV0_4r-zgQRL for ; Mon, 6 Jul 2015 00:16:49 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F56F1A0398 for ; Mon, 6 Jul 2015 00:16:49 -0700 (PDT) Received: by pdbdz6 with SMTP id dz6so5529642pdb.0 for ; Mon, 06 Jul 2015 00:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oMQaduRkUHm/GRN8ZvkT9tjhxjqSh7KsfPUwM22TXEs=; b=DcUJCISD8Xq9AwXD3tM+nSCF5G+K8E0IcPlnlDInmKHFx1jlSGHR5aHL66AVGFFbHp E9LCmTJdFNUVjDu0cwSzC8CKTKWYAB8zLenPpN35z7uI7ysCmJi1zOHvXqCPPTw9r7op ++FR6slc7vBLdzvNnbOL3ZlUQz4lOODON/glih/CE4neYXQHjwLYuG8sU3+I5ETHn0UC lOPAosIT3q3kca9Qu8HWEOXtK4kjaNvJWYUzQei/+JRKTtDN9N1PCUByV0naH5KrTpGV H5u6pREubdrNCNrXwmHamChe6helJgxBxlZZ1OO+CZSMBlYkhlVBLEf1ocGJX+UIDLTV 1wfA== X-Received: by 10.68.244.197 with SMTP id xi5mr101395061pbc.45.1436167008972; Mon, 06 Jul 2015 00:16:48 -0700 (PDT) Received: from [192.168.1.100] ([1.149.200.94]) by mx.google.com with ESMTPSA id ly7sm17064781pdb.17.2015.07.06.00.16.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jul 2015 00:16:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: James Winterbottom In-Reply-To: Date: Mon, 6 Jul 2015 17:16:43 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <64C1EB91-8597-4E97-9A2F-DDE031E3355E@gmail.com> References: <20150706054726.16271.85157.idtracker@ietfa.amsl.com> To: Randall Gellens X-Mailer: Apple Mail (2.2098) Archived-At: Cc: ecrit@ietf.org Subject: Re: [Ecrit] Status of draft-ietf-ecrit-additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 07:16:51 -0000 Thanks for all your efforts Randy! > On 6 Jul 2015, at 3:52 pm, Randall Gellens = wrote: >=20 > I wanted to let everyone know that version -30 addressed all of = Alissa's and Keith's comments, version -32 addressed the remaining = issues identified by Matt, and version -33 fixed a potentially ambiguous = sentence I noticed. So, -33 is version that is ready for last call. >=20 > At 10:47 PM -0700 7/5/15, internet-drafts@ietf.org wrote: >=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Emergency Context Resolution with = Internet Technologies Working Group of the IETF. >>=20 >> Title : Additional Data Related to an Emergency = Call >> Authors : Randall Gellens >> Brian Rosen >> Hannes Tschofenig >> Roger Marshall >> James Winterbottom >> Filename : draft-ietf-ecrit-additional-data-32.txt >> Pages : 110 >> Date : 2015-07-05 >>=20 >> Abstract: >> When an emergency call is sent to a Public Safety Answering Point >> (PSAP), the originating device, the access network provider to = which >> the device is connected, and all service providers in the path of = the >> call have information about the call, the caller or the location >> which is helpful for the PSAP to have in handling the emergency. >> This document describes data structures and mechanisms to convey = such >> data to the PSAP. The intent is that every emergency call carry = the >> information described here using the mechanisms described here. >>=20 >> The mechanisms permit the data to be conveyed by reference (as an >> external resource) or by value (within the body of a SIP message = or a >> location object). This follows the tradition of prior emergency >> services standardization work where data can be conveyed by value >> within the call signaling (i.e., in the body of the SIP message) = or >> by reference. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-ecrit-additional-data-32 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-32= >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > Hollywood is where if you don't have happiness you send out for it. > --Rex Reed >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Mon Jul 6 12:19:45 2015 Return-Path: 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 432F51B3047; Mon, 6 Jul 2015 12:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9bW2Ir6H3inA; Mon, 6 Jul 2015 12:19:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAEB1B304C; Mon, 6 Jul 2015 12:19:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706191942.28978.18266.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 12:19:42 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 19:19:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Next-Generation Pan-European eCall Authors : Randall Gellens Hannes Tschofenig Filename : draft-ietf-ecrit-ecall-03.txt Pages : 43 Date : 2015-07-06 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of the Pan European in- vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles. eCall deployment is required in the very near future in European Union member states, and eCall (and eCall- compatible systems) are also being deployed in other regions. eCall provides an integrated voice path and a standardized set of vehicle, sensor (e.g., crash related), and location data. An eCall is recognized and handled as a specialized form of emergency call and is routed to a specialized eCall-capable Public Safety Answering Point (PSAP) capable of processing the vehicle data and trained in handling emergency calls from vehicles. Currently, eCall functions over circuit-switched cellular telephony; work on next-generation eCall (NG-eCall, sometimes called packet- switched eCall or PS-eCall) is now in process, and this document assists in that work by describing how to support eCall within the IP-based emergency services infrastructure. This document also registers a MIME Content Type and an Emergency Call Additional Data Block for the eCall vehicle data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-ecall-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 12:20:09 2015 Return-Path: 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 E93AC1B3063; Mon, 6 Jul 2015 12:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 SPe1g48btdSp; Mon, 6 Jul 2015 12:20:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D69AE1B305D; Mon, 6 Jul 2015 12:19:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706191955.19689.42703.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 12:19:55 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 19:20:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Next-Generation Vehicle-Initiated Emergency Calls Authors : Randall Gellens Brian Rosen Hannes Tschofenig Filename : draft-ietf-ecrit-car-crash-03.txt Pages : 22 Date : 2015-07-06 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data. This document also registers a MIME Content Type and an Emergency Call Additional Data Block for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash). An external specification for the data format, contents, and structure are referenced in this document. Profiling and simplifications of the general emergency call mechanism, as described in [RFC6443] and [RFC6881], are possible due to the nature of the functionality that is provided in vehicles such as the usage of Global Satellite Navigation System (GNSS). This document reuses the technical aspects of next-generation pan- European eCall (a mandated and standardized system for emergency calls by in-vehicle systems within Europe and other regions), as described in [I-D.ietf-ecrit-ecall]. However, this document specifies a different set of vehicle (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 16:49:40 2015 Return-Path: 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 A1EA91A1BF3 for ; Mon, 6 Jul 2015 16:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 UM57qWZ5oFW4 for ; Mon, 6 Jul 2015 16:49:34 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935141A00EE for ; Mon, 6 Jul 2015 16:49:34 -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=1436226575; x=1467762575; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=er6AW84PCqIb8McqyczMbKySb7CFhQf4nXzaznXOMWY=; b=qYj0wQVHXl0KcxFo13VnpBw0lnhsgCFR+f9xtVL08AIP8DQDdx43HpTo xrAxKs4de6jc6TC42ANS6yK+euO1Zw2SfS7YnCyd4pGm1hfqHq6/aV27i S/hxEGoyoHKJ1JHv474bb0dEPPQrst4lZWgi7/1TU35dtJMtaFplpyvcE o=; X-IronPort-AV: E=McAfee;i="5700,7163,7854"; a="92151672" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jul 2015 16:49:34 -0700 X-IronPort-AV: E=Sophos;i="5.15,418,1432623600"; d="scan'208";a="955109185" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Jul 2015 16:49:12 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 6 Jul 2015 16:47:30 -0700 Message-ID: In-Reply-To: References: <20150706054726.16271.85157.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Mon, 6 Jul 2015 16:47:28 -0700 To: Randall Gellens , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 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: Cc: ecrit@ietf.org Subject: Re: [Ecrit] Status of draft-ietf-ecrit-additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 23:49:39 -0000 Oops, typo, I meant "Version -32 is the one that is ready for last call." At 10:52 PM -0700 7/5/15, Randall Gellens wrote: > I wanted to let everyone know that version -30 addressed all of > Alissa's and Keith's comments, version -32 addressed the remaining > issues identified by Matt, and version -33 fixed a potentially > ambiguous sentence I noticed. So, -33 is version that is ready for > last call. > > At 10:47 PM -0700 7/5/15, internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> This draft is a work item of the Emergency Context Resolution >> with Internet Technologies Working Group of the IETF. >> >> Title : Additional Data Related to an Emergency Call >> Authors : Randall Gellens >> Brian Rosen >> Hannes Tschofenig >> Roger Marshall >> James Winterbottom >> Filename : draft-ietf-ecrit-additional-data-32.txt >> Pages : 110 >> Date : 2015-07-05 >> >> Abstract: >> When an emergency call is sent to a Public Safety Answering Point >> (PSAP), the originating device, the access network provider to which >> the device is connected, and all service providers in the path of the >> call have information about the call, the caller or the location >> which is helpful for the PSAP to have in handling the emergency. >> This document describes data structures and mechanisms to convey such >> data to the PSAP. The intent is that every emergency call carry the >> information described here using the mechanisms described here. >> >> The mechanisms permit the data to be conveyed by reference (as an >> external resource) or by value (within the body of a SIP message or a >> location object). This follows the tradition of prior emergency >> services standardization work where data can be conveyed by value >> within the call signaling (i.e., in the body of the SIP message) or >> by reference. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-ecrit-additional-data-32 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-32 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > Hollywood is where if you don't have happiness you send out for it. > --Rex Reed > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- There are two kinds of light--the glow that illuminates, and the glare that obscures. --James Thurber From nobody Mon Jul 6 20:30:52 2015 Return-Path: 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 E89581A8935; Mon, 6 Jul 2015 20:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 4O5Nbm9KK91Z; Mon, 6 Jul 2015 20:30:47 -0700 (PDT) Received: from BLU004-OMC4S35.hotmail.com (blu004-omc4s35.hotmail.com [65.55.111.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64E71A8931; Mon, 6 Jul 2015 20:30:46 -0700 (PDT) Received: from BLU406-EAS354 ([65.55.111.137]) by BLU004-OMC4S35.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 6 Jul 2015 20:30:45 -0700 X-TMN: [d04n3lF1/Sh1VrscukE0p27pru0lDctD] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: Bernard Aboba MIME-Version: 1.0 (1.0) Date: Mon, 6 Jul 2015 20:30:44 -0700 References: <20150626153605.18943.13946.idtracker@ietfa.amsl.com> To: "Rosen, Brian" In-Reply-To: X-OriginalArrivalTime: 07 Jul 2015 03:30:45.0863 (UTC) FILETIME=[4F7E4F70:01D0B865] Archived-At: Cc: "iesg@ietf.org" , Randall Gellens , "ecrit@ietf.org" , ietf@ietf.org Subject: Re: [Ecrit] [new-work] WG Review: Selection of Language for Internet Media (slim) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 03:30:51 -0000 SSBhZ3JlZSB0aGF0IHRoZSAiZGlyZWN0IiBtb2RlbCBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0IGlz IHZlcnkgcHJvYmxlbWF0aWMuICBPbmUgb2YgdGhlIGd1aWRpbmcgcHJpbmNpcGxlcyBvZiBhY2Nl c3NpYmlsaXR5IGlzIHRoYXQgc2VydmljZXMgbmVlZCB0byBiZSBhdmFpbGFibGUgYXMgd2lkZWx5 IGFzIHBvc3NpYmxlIGdpdmVuIFBTQVAgY2FwYWJpbGl0aWVzLiBBdHRlbXB0aW5nIHRvIHJvdXRl IFZSUyBlbWVyZ2VuY3kgY2FsbHMgZGlyZWN0bHkgd2lsbCBhY3R1YWxseSBkcmFtYXRpY2FsbHkg cmVkdWNlIHRoZSBhYmlsaXR5IG9mIGRpc2FibGVkIHVzZXJzIHRvIHJlYWNoIGVtZXJnZW5jeSBz ZXJ2aWNlcyBzaW5jZSB2aWRlbyBjb3VsZCBub3QgYmUgYWNjZXB0ZWQgdW50aWwgdGhlIFBTQVAg aXMgZXF1aXBwZWQgdG8gaGFuZGxlIGl0LCBldmVuIGlmIHRoZSBpbnRlcnByZXRhdGlvbiBzZXJ2 aWNlIHdlcmUgYWJsZSB0byBkbyBzbywgYW5kIGEgY2FsbCByb3V0ZWQgdmlhIHRoZSBpbnRlcnBy ZXRpbmcgc2VydmljZSBjb3VsZCBzdWNjZWVkIHdpdGggZnVsbCBmdW5jdGlvbmFsaXR5LiANCg0K VGhlc2UgYXJlIGV4YWN0bHkgdGhlIGtpbmRzIG9mIGlzc3VlcyB0aGF0IHdvdWxkIGJlIGRlYmF0 ZWQgYW5kIGFkZHJlc3NlZCB3aXRoaW4gYSBXRyB3aXRoIGFwcHJvcHJpYXRlIFJBSSBmb2N1cywg YnV0IHdoaWNoIGFyZSBsaWtlbHkgdG8gYmUgbmVnbGVjdGVkIGluIGEgV0cgd2hvc2UgQ2hhcnRl ciBjb3ZlcnMgYm90aCBlbWVyZ2VuY3kgc2VydmljZSBhY2Nlc3NpYmlsaXR5IGlzc3VlcyBhbmQg ZW1haWwgbGFuZ3VhZ2Ugc2VsZWN0aW9uLiANCg0KQXQgYSBtaW5pbXVtLCBJIHdvdWxkIGxpa2Ug dG8gc2VlIGFub3RoZXIgd29yayBpdGVtIHJlbGF0aW5nIHRvIHVzZSBvZiB0aGUgcHJvcG9zZWQg bGFuZ3VhZ2Ugc3BlY2lmaWNhdGlvbiwgaW5jbHVkaW5nIGNhbGwgZmxvd3MsIHdpdGhpbiBhIGdy b3VwIHdpdGggZW1lcmdlbmN5IHNlcnZpY2VzIG9yIFNJUCBleHBlcnRpc2UgKHN1Y2ggYXMgRUNS SVQpLiANCg0KDQoNCg0KDQo+IE9uIEp1bCA2LCAyMDE1LCBhdCA3OjEzIFBNLCBSb3NlbiwgQnJp YW4gPEJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PiB3cm90ZToNCj4gDQo+IFdoaWxlIEkgdGhpbmsg dGhlIOKAnGRpcmVjdCBtb2RlbOKAnSBpcyBhY3R1YWxseSB2ZXJ5IHByb2JsZW1hdGljLCBJIHRo aW5rDQo+IHRoYXQgZHJhZnQgaXMgcXVpdGUgYXBwcm9wcmlhdGUgZm9yIHRoZSBiYXNpYyBwdXJw b3NlIG9mIG1ha2luZyBzdXJlIGENCj4gdHJhaW5lZCBjYWxsIHRha2VyIGdldHMgdGhlIGNhbGwu ICBBbmQsIG9mIGNvdXJzZSwgaXTigJlzIGFsc28gdmVyeSB1c2VmdWwNCj4gZm9yIGdlbmVyaWMg cm91dGluZyBvZiBjYWxscyBmb3Igd2hpY2ggYSBWUlMgYXMgYSDigJx0cmFuc2NvZGVy4oCdIHdv dWxkIGJlIGENCj4gbXVjaCBiZXR0ZXIgd2F5IHRvIG1ha2UgYSBnZW5lcmljIHZpZGVvIGNhbGwg bG9vayBkaWZmZXJlbnRseSBmcm9tIGEgVlJTDQo+IHZpZGVvIGNhbGwsIGFuZCBpbnZva2UgcHJv cGVyIHRyZWF0bWVudC4NCj4gDQo+IEl04oCZcyBhbHNvIGEgYmV0dGVyIHdheSB0byBhbm5vdW5j ZSBhIFZSUyBjYWxsIHRvIHRoZSBjYWxsIHRha2VyLiAgVG9kYXksDQo+IHdlIGRvbuKAmXQga25v dyBpdCBmcm9tIGFueSBvdGhlciAzcmQgcGFydHkgaW5pdGlhdGVkIHZpZGVvIGNhbGwuDQo+IA0K PiBBcyBSYW5keSBzYXlzLCB3ZeKAmXZlIGRpc2N1c3NlZCB0aGVzZSBpc3N1ZXMgd2l0aCB0aGUg TkVOQSBBY2Nlc3NpYmlsaXR5DQo+IGdyb3VwcyBhcyB3ZWxsIGFzIHRoZSBGQ0MgYWNjZXNzaWJp bGl0eSBjb21taXR0ZWUgZm9sa3MuICBXZeKAmXZlIGFsc28gYmVlbg0KPiBkaXNjdXNzaW5nIHRo ZSBpc3N1ZXMgd2l0aCBQU0FQcyB3aG8gaGF2ZSBzb21lIG11bHRpLWxpbmd1YWwgY2FsbCB0YWtl cnMsDQo+IGFuZCB3b3VsZCB2ZXJ5IG11Y2ggYXBwcmVjaWF0ZSBiZWluZyBhYmxlIHRvIHJvdXRl IHRvIHRoZSByaWdodCBxdWV1ZS4NCj4gQW5kLCBvZiBjb3Vyc2UsIGltcHJvdmluZyBob3cgUFNB UHMgaGFuZGxlIOKAnExhbmd1YWdlIExpbmXigJ0gc2VydmljZXMgaXMgb25lDQo+IG9mIHRoZSBi YXNpYyBnb2FscyBvZiB0aGlzIHdvcmsuICBUaGUgZGlyZWN0IG1vZGVsIHdvdWxkIG1ha2UgVlJT IGxvb2sNCj4gZXhhY3RseSBsaWtlIExhbmd1YWdlIExpbmUuDQo+IA0KPiBCcmlhbg0KPiANCj4g DQo+IA0KPiANCj4gDQo+PiBPbiA3LzYvMTUsIDg6MzUgUE0sICJSYW5kYWxsIEdlbGxlbnMiIDxy YW5keUBxdGkucXVhbGNvbW0uY29tPiB3cm90ZToNCj4+IA0KPj4gSGkgQmVybmFyZCwNCj4+IA0K Pj4gSSdkIGxpa2UgdG8gZGlzY3VzcyB5b3VyIGNvbmNlcm5zIGEgYml0LiAgSSd2ZSBhZGRlZCBC cmlhbiBSb3NlbiB0bw0KPj4gdGhlIGVtYWlsIGFzIGhlIGlzIGNoYWlyIG9mIHRoZSBORyAoaTMp IGFyY2hpdGVjdHVyZSBncm91cCBpbiBORU5BLg0KPj4gDQo+PiBJJ20gdHJ5aW5nIHRvIHVuZGVy c3RhbmQgd2h5IHlvdSBiZWxpZXZlIHRoYXQgdGhlIGNhbGwgZmxvdyBpbiA0LjUNCj4+IHdvdWxk IHJlc3VsdCBpbiByZWplY3Rpb24gb2YgdGhlIHZpZGVvIHN0cmVhbSwgcmF0aGVyIHRoYW4gdGhl IFBTQVANCj4+IGVuZ2FnaW5nIGFuIGludGVycHJldGF0aW9uIHNlcnZpY2UuICBBcyB5b3Ugc2F5 LCB3ZSBhcmUgdHJ5aW5nIHRvDQo+PiBtb3ZlIGZyb20gdG9kYXkncyBtb2RlbCBpbiB3aGljaCB0 aGUgY2FsbGVyIGZpcnN0IGNhbGxzIHRoZSByZWxheQ0KPj4gc2VydmljZSwgYW5kIHRoZW4gdGhl IHJlbGF5IHNlcnZpY2UgYnJpZGdlcyBpbiB0aGUgUFNBUCwgdG8gYSBkaXJlY3QNCj4+IG1vZGVs IHdoZXJlIHRoZSBjYWxsZXIgY2FsbHMgOTExIGRpcmVjdGx5LCBhbmQgdGhlIFBTQVAgYnJpZGdl cyBpbg0KPj4gdGhlIHJlbGF5IHNlcnZpY2UuICBPYnZpb3VzbHksIHRoZXJlIGFyZSBmdW5kaW5n IGlzc3VlcyB0aGF0IHdvdWxkDQo+PiBuZWVkIHRvIGJlIGhhbmRsZWQgaW4gb3JkZXIgZm9yIFBT QVBzIHRvIGJlIGFibGUgdG8gaW52b2tlIHJlbGF5DQo+PiBzZXJ2aWNlcywgYnV0IGJvdGggdGhl IG5leHQtZ2VuIGFuZCBhY2Nlc3NpYmlsaXR5IGdyb3VwcyBpbiBORU5BIHdhbnQNCj4+IGEgZGly ZWN0IG1vZGVsICh3aGljaCBvZmZlcnMgbWFueSBhZHZhbnRhZ2VzLCBpbmNsdWRpbmcgcHJpb3Jp dHkNCj4+IHRyZWF0bWVudCBhbmQgbG9jYXRpb24gZGVsaXZlcnkpLiAgVGhlIE5FTkEgUG9saWN5 LUJhc2VkIFJvdXRpbmcNCj4+IChQQlIpIGZ1bmN0aW9uYWxpdHkgd2l0aGluIGFuIEVTSW5ldCBo YXMgdGhlIGFiaWxpdHkgdG8gdXNlIHRoZSBTRFANCj4+IHdoZW4gbWFraW5nIHJvdXRpbmcgZGVj aXNpb25zIChpbiBjYXNlIFBTQVBzIGhhdmUgY29vcGVyYXRpb24NCj4+IGFncmVlbWVudHMgd2hl cmUgc29tZSBQU0FQcyBoYW5kbGUgc29tZSB0eXBlcyBvZiBjYWxscyBvciBzb21lDQo+PiBsYW5n dWFnZXMgb3IgbWVkaWEpLg0KPj4gDQo+PiBUaGUgZHJhZnQgYW5kIHRoZSBpc3N1ZXMgaGF2ZSBi ZWVuIGRpc2N1c3NlZCB3aXRoIHRoZSBjby1jaGFpcnMgb2YNCj4+IHRoZSBORU5BIGFjY2Vzc2li aWxpdHkgV0csIGFuZCB0aGV5IGFyZSBzdHJvbmdseSBpbiBmYXZvciBvZiBhIGRpcmVjdA0KPj4g bW9kZWwgZm9yIG5leHQtZ2VuLg0KPj4gDQo+PiBJbiB0aGUgVS5TLiwgZW1lcmdlbmN5IGNhbGwg cm91dGluZyBpcyBmaXJzdCBieSBsb2NhdGlvbiwgYW5kIHRoZW4gYnkNCj4+IGxvY2FsIHJ1bGVz IChpZiBhbnkpLiAgRm9yIGV4YW1wbGUsIGlmIGEgY2FsbCByZXF1aXJlcyB0ZXh0LCB0aGVyZQ0K Pj4gbWlnaHQgYmUgc29tZSBQU0FQcyBpbiBhIGNvb3BlcmF0aW5nIGdyb3VwIHRoYXQgdGFrZSB0 ZXh0IGNhbGxzIG9uDQo+PiBiZWhhbGYgb2Ygb3RoZXJzLiAgTGlrZXdpc2UgaWYgdGhlIGNhbGwg cmVxdWVzdHMgYXVkaW8gb3IgdGV4dHVhbA0KPj4gU3BhbmlzaC4gIEluIEV1cm9wZSwgdmFyaW91 cyBtb2RlbHMgYXJlIHVuZGVyIGRpc2N1c3Npb24sIGluY2x1ZGluZw0KPj4gc29tZSBpbiB3aGlj aCBhIGNhbGwgbWlnaHQgYmUgcm91dGVkIHRvIGEgUFNBUCBpbiBhIGNvdW50cnkgd2hlcmUgdGhl DQo+PiBjYWxsZXIncyBsYW5ndWFnZSBpcyBuYXRpdmUuICBUaGUgZHJhZnQgYWxsb3dzIHRoaXMg ZmxleGliaWxpdHk6IHRoZQ0KPj4gY2FsbCBjYW4gYmUgcm91dGVkIHRvIGEgc3BlY2lmaWMgUFNB UCAoYW5kIGV2ZW4gY2FsbCB0YWtlcikgb3IgdGhlDQo+PiBQU0FQIGNhbiBicmlkZ2UgaW4gdHJh bnNsYXRpb24gb3IgcmVsYXkgc2VydmljZXMgYXQgdGhlIHN0YXJ0IG9mIHRoZQ0KPj4gY2FsbC4N Cj4+IA0KPj4gQXQgNToxNSBQTSAtMDcwMCA3LzEvMTUsIEJlcm5hcmQgQWJvYmEgd3JvdGU6DQo+ PiANCj4+PiBJIGJlbGlldmUgdGhhdCB0aGlzIENoYXJ0ZXIgaXMgcG9vcmx5IHN1aXRlZCB0byBk ZXZlbG9waW5nDQo+Pj4gc29sdXRpb25zIHRvIHRoZSBwcm9ibGVtIGZhY2VkIGJ5IGRpc2FibGVk IHVzZXJzIG9mIHJlYWx0aW1lDQo+Pj4gZW1lcmdlbmN5IHNlcnZpY2VzLg0KPj4+IA0KPj4+IElu IHRoZSBjYXNlIG9mIGFjY2VzcyB0byBlbWVyZ2VuY3kgc2VydmljZXMgYnkgdGhlIGRpc2FibGVk LCB0aGUNCj4+PiBnb2FsIGlzIG5vdCAic2VsZWN0aW9uIG9mIHRoZSBiZXN0LWZpdCBsYW5ndWFn ZSIsIGJ1dCByYXRoZXIsDQo+Pj4gcm91dGluZyBvZiB0aGUgY2FsbCBhbmQgbWVkaWEgc28gYXMg dG8gcHVsbCB0b2dldGhlciB0aGUgc2VydmljZXMNCj4+PiBiZXN0IGZpdHRpbmcgdGhlIGVtZXJn ZW5jeSBzaXR1YXRpb24gYW5kIHRoZSBkaXNhYmlsaXRpZXMgb2YgdGhlDQo+Pj4gY2FsbGVyLCBh cyB3ZWxsIGFzIHRoZSBjYXBhYmlsaXRpZXMgb2YgdGhlIGRldmljZSBhbmQNCj4+PiBpbnRlcm1l ZGlhcmllcyB3aGljaCBtYXkgc2l0IGJldHdlZW4gdGhlIGNhbGxlciBhbmQgdGhlIFBTQVAuICBO b3QNCj4+PiBvbmx5IGFyZSBtZWRpYSBhbmQgbGFuZ3VhZ2UgaW50cmluc2ljYWxseSBsaW5rZWQs IGJ1dCBhbHNvLCB0aGUNCj4+PiB3YXlzIGluIHdoaWNoIGNhbGxzIGFyZSByb3V0ZWQgaXMgaW5m bHVlbmNlZCBhbmQgaW4gc29tZSBjYXNlcw0KPj4+IHByZXNjcmliZWQgYnkgcmVndWxhdGlvbiBh bmQgbmF0aW9uYWwgc3RhbmRhcmRzLg0KPj4+IA0KPj4+IFNpbXBseSBwdXQsIGRyYWZ0LWdlbGxl bnMtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZSBsYWNrcw0KPj4+IGFwcHJvcHJpYXRl IGNvbnNpZGVyYXRpb24gb2YgdGhlIHByb2JsZW0gY29udGV4dC4gIFNwZWNpZnlpbmcgaXQgYXMN Cj4+PiB0aGUgc3RhcnRpbmcgcG9pbnQgaXMgdGhlcmVmb3JlIGluYXBwcm9wcmlhdGUuIEFzIGFu IGV4YW1wbGUsIHRvZGF5DQo+Pj4gdGhlIGNhbGwgZmxvdyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0 LjUgd291bGQgbW9zdCBsaWtlbHkgcmVzdWx0IGluDQo+Pj4gcmVqZWN0aW9uIG9mIHRoZSB2aWRl byBwb3J0aW9uIG9mIHRoZSBjYWxsIGJ5IHRoZSBQU0FQLCBsZWF2aW5nIHRoZQ0KPj4+IGRpc3Bh dGNoZXIgd2l0aCBubyBtZWFucyBvZiBjb21tdW5pY2F0aW5nIHdpdGggdGhlIGhlYXJpbmctaW1w YWlyZWQNCj4+PiBjYWxsZXIsIHRodXMgbGVhdmluZyB0aGUgY2FsbGVyIHdvcnNlIG9mZiB0aGFu IHRoZXkgYXJlIHRvZGF5DQo+Pj4gYXR0ZW1wdGluZyB0byBtYWtlIGFuIGVtZXJnZW5jeSBjYWxs IHdpdGhpbiB0aGUgKGN1bWJlcnNvbWUgYW5kDQo+Pj4gZXJyb3IvZGVsYXktcHJvbmUpIFZpZGVv IFJlbGF5IFNlcnZpY2UuICAgQSBmdWxsZXIgY29uc2lkZXJhdGlvbiBvZg0KPj4+IHRoZSBwcm9i bGVtIGNvbnRleHQgd291bGQgaW52b2x2ZSBjb25zaWRlcmF0aW9uIG9mIGN1cnJlbnQNCj4+PiBv cGVyYXRpb24gb2YgcmVsYXkgc2VydmljZXMgYW5kIHByb3Bvc2FscyBmb3IgdGhlaXIgZXZvbHV0 aW9uLg0KPj4+IEF0dGVtcHRpbmcgdG8gZGV2ZWxvcCB0aGlzIHByb2JsZW0gY29udGV4dCB3aXRo aW4gYSBXRyB0aGF0IGlzDQo+Pj4gYWxzbyBhdHRlbXB0aW5nIHRvIGRlYWwgd2l0aCBsYW5ndWFn ZS1zZWxlY3Rpb24gaW4gZW1haWwgd291bGQgYmUNCj4+PiBmcnVzdHJhdGluZyBhdCBiZXN0Lg0K Pj4+IA0KPj4+IEEgc2Vuc2libGUgQ2hhcnRlciB3b3VsZCBhbHNvIHByb2JhYmx5IGluY2x1ZGUg bGlhaXNvbnMgd2l0aA0KPj4+IGRpc2FiaWxpdHkgcmlnaHRzIG9yZ2FuaXphdGlvbnMsIGdyb3Vw cyBzcGVjaWZ5aW5nIHRoZSBvcGVyYXRpb24gb2YNCj4+PiByZWxheSBzZXJ2aWNlcywgYW5kIGdy b3VwcyBjb25zaWRlcmluZyBuZXh0IHN0ZXBzIGZvciBhY2Nlc3MgdG8NCj4+PiBlbWVyZ2VuY3kg c2VydmljZXMuDQo+Pj4gDQo+Pj4+IEZyb206IGllc2dAaWV0Zi5vcmcNCj4+Pj4gVG86IG5ldy13 b3JrQGlldGYub3JnDQo+Pj4+IERhdGU6IEZyaSwgMjYgSnVuIDIwMTUgMDg6MzY6MDUgLTA3MDAN Cj4+Pj4gU3ViamVjdDogW25ldy13b3JrXSBXRyBSZXZpZXc6IFNlbGVjdGlvbiBvZiBMYW5ndWFn ZSBmb3IgSW50ZXJuZXQNCj4+Pj4gTWVkaWEgKHNsaW0pDQo+Pj4+IA0KPj4+PiBBIG5ldyBJRVRG IHdvcmtpbmcgZ3JvdXAgaGFzIGJlZW4gcHJvcG9zZWQgaW4gdGhlIEFwcGxpY2F0aW9ucyBhbmQN Cj4+Pj4gUmVhbC1UaW1lIEFyZWEuIFRoZSBJRVNHIGhhcyBub3QgbWFkZSBhbnkgZGV0ZXJtaW5h dGlvbiB5ZXQuIFRoZQ0KPj4+PiBmb2xsb3dpbmcgZHJhZnQgY2hhcnRlciB3YXMgc3VibWl0dGVk LCBhbmQgaXMgcHJvdmlkZWQgZm9yDQo+Pj4+IGluZm9ybWF0aW9uYWwNCj4+Pj4gcHVycG9zZXMg b25seS4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgSUVTRyBtYWlsaW5nIGxpc3QN Cj4+Pj4gKGllc2cNCj4+Pj4gYXQgaWV0Zi5vcmcpIGJ5IDIwMTUtMDctMDYuDQo+Pj4+IA0KPj4+ PiBTZWxlY3Rpb24gb2YgTGFuZ3VhZ2UgZm9yIEludGVybmV0IE1lZGlhIChzbGltKQ0KPj4+PiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4gQ3Vy cmVudCBTdGF0dXM6IFByb3Bvc2VkIFdHDQo+Pj4+IA0KPj4+PiBBc3NpZ25lZCBBcmVhIERpcmVj dG9yOg0KPj4+PiBCYXJyeSBMZWliYSA8YmFycnlsZWliYUBjb21wdXRlci5vcmc+DQo+Pj4+IA0K Pj4+PiBNYWlsaW5nIGxpc3QNCj4+Pj4gQWRkcmVzczogc2xpbUBpZXRmLm9yZw0KPj4+PiBUbyBT dWJzY3JpYmU6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2xpbQ0KPj4+ PiBBcmNoaXZlOiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL3NsaW0v DQo+Pj4+IA0KPj4+PiBDaGFydGVyOg0KPj4+PiANCj4+Pj4gRGVzY3JpcHRpb24gb2YgV29ya2lu ZyBHcm91cDoNCj4+Pj4gDQo+Pj4+IEEgbXV0dWFsbHkgY29tcHJlaGVuc2libGUgbGFuZ3VhZ2Ug aXMgaGVscGZ1bCBmb3IgaHVtYW4gY29tbXVuaWNhdGlvbi4NCj4+Pj4gVGhpcyBpcyB0cnVlIGFj cm9zcyBhIHJhbmdlIG9mIGNpcmN1bXN0YW5jZXMgYW5kIGVudmlyb25tZW50cy4gSW4NCj4+Pj4g Z2VuZXJhbCwgdGhlIHByb2JsZW0gaXMgbW9zdCBhY3V0ZSBpbiBzaXR1YXRpb25zIHdoZXJlIHRo ZXJlIGlzIG5vdCBhDQo+Pj4+IGNsZWFyIGNob2ljZSBmb3IgYSBzaW5nbGUgbGFuZ3VhZ2UsIHN1 Y2ggYXMgZW52aXJvbm1lbnRzIGxhY2tpbmcNCj4+Pj4gY29udGV4dHVhbCBvciBvdXQtb2YtYmFu ZCBpbmZvcm1hdGlvbiByZWdhcmRpbmcgdGhlIGlkZW50aXR5IG9mIHRoZQ0KPj4+PiBwYXJ0aWVz IGFuZCB0aGUgbGFuZ3VhZ2UgdG8gYmUgdXNlZC4NCj4+Pj4gDQo+Pj4+IFRoZSBncm91cCB3aWxs IGFkZHJlc3MgdHdvIHNwZWNpZmljIGNhc2VzIHRoYXQgbW9zdCB1cmdlbnRseSBuZWVkIGENCj4+ Pj4gdGVjaG5pY2FsIHNvbHV0aW9uOiBPbmUgcHJvYmxlbSBzcGFjZSBpcyBub24tcmVhbC10aW1l IGNvbW11bmljYXRpb24sDQo+Pj4+IHNwZWNpZmljYWxseSBlbWFpbCBmb3Igb25lLXRvLW1hbnkg b3Igd2hlcmUgdGhlIHNldCBvZiByZWNpcGllbnRzIGlzDQo+Pj4+IGR5bmFtaWMgb3IgZGlmZmVy ZW50IHJlY2lwaWVudHMgcmVxdWlyZSBkaWZmZXJlbnQgbGFuZ3VhZ2VzOyB0aGUNCj4+Pj4gb3Ro ZXIgaXMNCj4+Pj4gcmVhbC10aW1lIGNvbW11bmljYXRpb24sIHNwZWNpZmljYWxseSBlbWVyZ2Vu Y3kgY2FsbGluZywgcHJlZmVyYWJseQ0KPj4+PiBhbHNvDQo+Pj4+IHVzZWZ1bCBmb3Igb3RoZXIg Y2FzZXMgd2hlcmUgdGhlIHBhcnRpZXMgbWF5IG5vdCBrbm93IGVhY2ggb3RoZXINCj4+Pj4gcGVy c29uYWxseSBvciB3aGVyZSBvbmUgcGFydHkgd2lzaGVzIHRvIGFjY29tbW9kYXRlIHBlb3BsZSB3 aXRoDQo+Pj4+IHZhcnlpbmcNCj4+Pj4gbGFuZ3VhZ2UgYW5kIG1lZGlhIG5lZWRzLg0KPj4+PiAN Cj4+Pj4gSW4gdGhlIHJlYWwtdGltZSBjb21tdW5pY2F0aW9uIGNhc2UsIGxhbmd1YWdlIGFuZCBt ZWRpYSBhcmUNCj4+Pj4gaW50cmluc2ljYWxseQ0KPj4+PiBsaW5rZWQsIGZvciBleGFtcGxlLCBz aWduZWQgbGFuZ3VhZ2VzIHJlcXVpcmUgYSB2aWRlbyBtZWRpYS4NCj4+Pj4gDQo+Pj4+IFdoaWxl IHRoZSB0d28gdXNlIGNhc2VzIGFyZSBpbiBkaWZmZXJlbnQgY29udGV4dHMgKHJlYWwgdGltZSBh bmQNCj4+Pj4gbm9uLXJlYWwtdGltZSksIHRoZSBmdW5kYW1lbnRhbCBnb2FsIGlzIHRoZSBzYW1l OiB0byBlbmFibGUgc2VsZWN0aW9uDQo+Pj4+IG9mDQo+Pj4+IHRoZSBiZXN0LWZpdCBsYW5ndWFn ZShzKSBmb3IgYSBzcGVjaWZpYyBzaXR1YXRpb24uIFNvbWUgb2YgdGhlIGRldGFpbHMNCj4+Pj4g d2lsbCBhbHNvIGJlIGluIGNvbW1vbiBhY3Jvc3MgdGhlIGNhc2VzLCBlLmcuLCB0aGUgbGFuZ3Vh Z2UgdGFncy4NCj4+Pj4gSGF2aW5nDQo+Pj4+IGEgc2luZ2xlIFdHIGFkZHJlc3MgYm90aCBjYXNl cyBtYWtlcyBpdCBjbGVhciB0aGF0IHRoZXNlIGFyZSB0d28NCj4+Pj4gYXNwZWN0cw0KPj4+PiBv ZiB0aGUgc2FtZSBiYXNpYyBwcm9ibGVtLiBBIHNpbmdsZSBXRyBhbHNvIG1ha2VzIGl0IGVhc2ll ciB0bw0KPj4+PiBtYXhpbWl6ZQ0KPj4+PiBzaW1pbGFyaXRpZXMgYW5kIGF2b2lkIHVubmVjZXNz YXJ5IGZyYWdtZW50YXRpb24gb2YgdGhlIHNvbHV0aW9ucywgYW5kDQo+Pj4+IGZhY2lsaXRhdGVz IGJyb2FkZXIgcmV2aWV3Lg0KPj4+PiANCj4+Pj4gVGhlIGdyb3VwIHdpbGwgcHJvZHVjZSB0d28g ZG9jdW1lbnRzLCBvbmUgZm9yIGVtYWlsLCBhbmQgb25lIGZvcg0KPj4+PiByZWFsLXRpbWUgY29t bXVuaWNhdGlvbnMuDQo+Pj4+IA0KPj4+PiBJbiB0aGUgZW1haWwgY2FzZSwgdGhlIGdyb3VwIHdp bGwgZGV0ZXJtaW5lIGEgTUlNRSBiYXNlZCBzb2x1dGlvbiB0aGF0DQo+Pj4+IGVuYWJsZXMgYSBz aW5nbGUgZW1haWwgbWVzc2FnZSB0byBjb250YWluIG11bHRpcGxlIGxhbmd1YWdlIHZlcnNpb25z DQo+Pj4+IG9mDQo+Pj4+IHRoZSBjb250ZW50LCB3aXRoIHByb3Zpc2lvbnMgdG8gaGVscCBjbGll bnRzIHNlbGVjdCBhIGJlc3QgZml0DQo+Pj4+IHZlcnNpb24uDQo+Pj4+IA0KPj4+PiBJbiB0aGUg cmVhbC10aW1lIGNvbW11bmljYXRpb24gY2FzZSwgdGhlIGdyb3VwIHdpbGwgcHJvZHVjZSBhDQo+ Pj4+IHNwZWNpZmljYXRpb24gYmFzZWQgb24gZHJhZnQtZ2VsbGVucy1zbGltLW5lZ290aWF0aW5n LWh1bWFuLWxhbmd1YWdlLA0KPj4+PiBlbmFibGluZyBuZWdvdGlhdGlvbiBvZiBhIGh1bWFuIGxh bmd1YWdlIHBlciBtZWRpYSBzdHJlYW0uIFRoZQ0KPj4+PiBzcGVjaWZpY2F0aW9uIG11c3QgYmUg c3VpdGFibGUgZm9yIHVzZSBpbiBlbWVyZ2VuY3kgY29tbXVuaWNhdGlvbnMgYXMNCj4+Pj4gc3Bl Y2lmaWVkIGluIFJGQyA2NDQzIGFuZCBSRkMgNjg4MSAod2hpY2ggdXNlIFNJUCBhbmQgU0RQIHRv IG5lZ290aWF0ZQ0KPj4+PiBtZWRpYSk7IGl0IGlzIGRlc2lyYWJsZSB0byBhbHNvIGJlIHN1aXRh YmxlIGZvciB1c2UgaW4gbm9uLWVtZXJnZW5jeQ0KPj4+PiByZWFsLXRpbWUgY29tbXVuaWNhdGlv bnMgdGhhdCBzaGFyZSB0aGUgc2FtZSBjYWxsIHNldC11cCBhbmQgbWVkaWENCj4+Pj4gbmVnb3Rp YXRpb24gcHJvdG9jb2xzLiBUaGUgbWVjaGFuaXNtIHdpbGwgcGVybWl0IHRoZSBjYWxsZXIncyBt ZWRpYQ0KPj4+PiBhbmQNCj4+Pj4gbGFuZ3VhZ2UgbmVlZHMgYW5kIHByZWZlcmVuY2VzIHRvIGJl IG1hdGNoZWQgYWdhaW5zdCB3aGF0IHRoZSBjYWxsZWQNCj4+Pj4gcGFydHkgaXMgYWJsZSB0byBw cm92aWRlLiBUaGUgbWVjaGFuaXNtIHdpbGwgcGVybWl0IHJlc291cmNlcyAoZS5nLiwNCj4+Pj4g dHJhbnNsYXRpb24sIHJlbGF5LCBtZWRpYSkgdG8gYmUgYWxsb2NhdGVkIG9yIGVuZ2FnZWQgYXMg ZWFybHkgYXMNCj4+Pj4gcG9zc2libGUgaW4gdGhlIGNhbGwgc2V0LXVwIG9yIGZvciB0aGUgY2Fs bCB0byBiZSByb3V0ZWQgb3IgaGFuZGxlZA0KPj4+PiBzcGVjaWFsbHkgKGUuZy4sIHJvdXRlZCB0 byBhIHJlc291cmNlIGFibGUgdG8gcHJvdmlkZSBhIG5lZWRlZA0KPj4+PiBsYW5ndWFnZQ0KPj4+ PiBhbmQvb3IgbWVkaWEpLiBBbHRlcm5hdGl2ZXMgc3VjaCBhcyBkb2luZyB0aGUgbmVnb3RpYXRp b24gaW4gU0lQIGhhdmUNCj4+Pj4gYmVlbiB0aG9yb3VnaGx5IGV4cGxvcmVkIGluIHRoZSBwYXN0 IGFuZCBhcmUgb3V0IG9mIHNjb3BlIChhbHRob3VnaA0KPj4+PiB0aGUNCj4+Pj4gc2NvcGUgbWln aHQgYmUgZXh0ZW5kZWQgYWZ0ZXIgdGhlIFNEUCBtZWNoYW5pc20gaGFzIGJlZW4gYWR2YW5jZWQp Lg0KPj4+PiANCj4+Pj4gQnkgYWRkaW5nIGxhbmd1YWdlIHRvIHRoZSBleGlzdGluZyBtZWRpYSBu ZWdvdGlhdGlvbiBtZWNoYW5pc20gYXMNCj4+Pj4gdXNlZCBpbg0KPj4+PiBSRkMgNjQ0MyBhbmQg UkZDIDY4ODEsIHRoZSBncm91cCBjYW4gbWVldCB0aGUgYmFzaWMgdXNlIGNhc2VzIHdpdGgNCj4+ Pj4gbWluaW1hbCBhZGRlZCBjb21wbGV4aXR5IGFuZCBiZSBhYmxlIHRvIGVuaGFuY2UgbGF0ZXIg Zm9yIGFkZGl0aW9uYWwNCj4+Pj4gdXNlDQo+Pj4+IGNhc2VzIGFzIG5lZWRlZC4NCj4+Pj4gDQo+ Pj4+IE1pbGVzdG9uZXM6DQo+Pj4+IE9jdCAyMDE1IC0gU3VibWl0ICJNdWx0aXBsZSBMYW5ndWFn ZSBDb250ZW50IFR5cGUiIHRvIHRoZSBJRVNHIChiYXNlZA0KPj4+PiBvbiBkcmFmdC10b21raW5z b24tc2xpbS1tdWx0aWxhbmdjb250ZW50KQ0KPj4+PiBGZWIgMjAxNiAtIFN1Ym1pdCAiTmVnb3Rp YXRpbmcgSHVtYW4gTGFuZ3VhZ2UgaW4gUmVhbC1UaW1lDQo+Pj4+IENvbW11bmljYXRpb25zIiB0 byB0aGUgSUVTRyAoYmFzZWQgb24NCj4+Pj4gZHJhZnQtZ2VsbGVucy1zbGltLW5lZ290aWF0aW5n LWh1bWFuLWxhbmd1YWdlKQ0KPj4+PiANCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IG5ldy13b3JrIG1haWxpbmcgbGlzdA0K Pj4+PiBuZXctd29ya0BpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldy13b3JrDQo+Pj4+IA0KPj4+IA0KPj4+IA0KPj4gDQo+PiANCj4+IA0KPj4g LS0gDQo+PiBSYW5kYWxsIEdlbGxlbnMNCj4+IE9waW5pb25zIGFyZSBwZXJzb25hbDsgICAgZmFj dHMgYXJlIHN1c3BlY3Q7ICAgIEkgc3BlYWsgZm9yIG15c2VsZiBvbmx5DQo+PiAtLS0tLS0tLS0t LS0tLSBSYW5kb21seSBzZWxlY3RlZCB0YWc6IC0tLS0tLS0tLS0tLS0tLQ0KPj4gSnVzdCBiZWNh dXNlIHlvdSBkbyBub3QgdGFrZSBhbiBpbnRlcmVzdCBpbiBwb2xpdGljcyBkb2Vzbid0IG1lYW4N Cj4+IHBvbGl0aWNzIHdvbid0IHRha2UgYW5kIGludGVyZXN0IGluIHlvdS4gIC0tUGVyaWNsZXMg KDQ5NS00MjUgQkMpDQo+IA0K From nobody Tue Jul 7 05:52:02 2015 Return-Path: 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 8253C1A02F1; Tue, 7 Jul 2015 05:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 c1q8ykyux5gR; Tue, 7 Jul 2015 05:51:54 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06D701A017D; Tue, 7 Jul 2015 05:51:54 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t67ChTWv024236; Tue, 7 Jul 2015 08:51:52 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1vg17urw39-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 07 Jul 2015 08:51:52 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.249]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 7 Jul 2015 08:51:52 -0400 From: "Rosen, Brian" To: Bernard Aboba Thread-Topic: [new-work] WG Review: Selection of Language for Internet Media (slim) Thread-Index: AQHQuEzltscDAESj6kOVJF21kF3Hkp3PREKAgABYzwCAAFmzgA== Date: Tue, 7 Jul 2015 12:51:51 +0000 Message-ID: References: <20150626153605.18943.13946.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.33.193.32] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-07_04:2015-07-07,2015-07-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "iesg@ietf.org" , Randall Gellens , "ecrit@ietf.org" , "ietf@ietf.org" Subject: Re: [Ecrit] [new-work] WG Review: Selection of Language for Internet Media (slim) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 12:51:57 -0000 QnV0IHRoZSBkcmFmdCBkb2VzbuKAmXQgc3VnZ2VzdCB0aGF0IHRoZSBkaXJlY3QgbW9kZWwgc2hv dWxkIHJlcGxhY2UgdGhlDQpjdXJyZW50IGVtZXJnZW5jeSBjYWxsIHJvdXRpbmcsIGl0IG1lcmVs eSBhbGxvd3MgbmV3IGNhcGFiaWxpdHkuICBJZiB0aGVyZQ0KaXMgYW55IGxhbmd1YWdlIHlvdSBm aW5kIHRoYXQgbWFrZXMgaXQgc2VlbSBsaWtlIGRpcmVjdCByb3V0aW5nIHNob3VsZCBiZQ0KcHJl ZmVycmVkIG92ZXIgdGhlIGN1cnJlbnQgbG9jYXRpb24gYmFzZWQgcm91dGluZywgd2UgY2FuIGFk ZHJlc3MgdGhhdC4NCg0KT24geW91ciBzcGVjaWZpYyBwb2ludCBhYm91dCBub3QgYmVpbmcgYWJs ZSB0byBkZWFsIHdpdGggbm9uLXZpZGVvDQplcXVpcHBlZCBQU0FQcywgd2UgaGF2ZSBwbGVudHkg b2YgbWVjaGFuaXNtcyBhdmFpbGFibGUgdG8gcmVhZGlseQ0KYWNjb21tb2RhdGUgdGhhdCBzaXR1 YXRpb24uICBEZXZpY2VzIGFyZSByZXF1aXJlZCB0byBmb2xsb3cgZXhpc3RpbmcNCnByYWN0aWNl IG9mIGZvcndhcmRpbmcgY2FsbHMgdG8gdGhlaXIgbm9ybWFsIG91dGJvdW5kIHByb3h5LCBhbmQg dGhpcw0KZHJhZnQgZG9lc27igJl0IGNoYW5nZSB0aGF0IGF0IGFsbC4gIFdoYXQgaGFwcGVucyBh ZnRlciB0aGF0IGlzIGNvbmZpbmVkIHRvDQp3aGF0IHRoZSBzZXJ2aWNlcyB0aGF0IHByb3ZpZGUg cm91dGluZyBmb3IgVlJTLCBhbmQgd2UgY2FuIGhhbmRsZSBsb2NhdGlvbg0Kc2Vuc2l0aXZlIGhh bmRsaW5nIG9mIHN1Y2ggY2FsbHMuICBBbGwgOS0xLTEgY2FsbHMgYXJlIOKAnGRpcmVjdOKAnSBy b3V0ZWQsIGluDQp0aGF0IHRoZXkgcm91dGUgdG8gdGhlIG91dGJvdW5kIHByb3h5LCB3aGljaCBy b3V0ZXMgYmFzZWQgb24gdGhlIExvU1QNCnF1ZXJ5IHJlc3VsdCwgYW5kIHRoYXQgaXMgbm90IG1l ZGlhIHNlbnNpdGl2ZS4gIFRoYXQgZGVsaXZlcnMgdGhlIGNhbGwgdG8NCnRoZSByaWdodCBpbmJv dW5kIHByb3h5IHNlcnZlciwgd2hpY2ggdGhlbiBpcyBhYmxlIHRvIHJvdXRlIGJhc2VkIG9uDQpt ZWRpYSwgaWYgZGVzaXJlZC4gDQoNClRoZSB3YXkgd2UgaGFuZGxlIFZSUywgYW5kIHN0aWxsIGdl dCBjYWxscyByb3V0ZWQgYnkgdGhlIGxvY2F0aW9uIG9mIHRoZQ0KY2FsbGVyIGlzIHRvIGhhdmUg dGhlIFZSUyBzZXJ2aWNlIHJvdXRlIHRoZSBjYWxsIGxpa2UgYW55IG90aGVyIDktMS0xIGNhbGwN CndvdWxkIGJlIHJvdXRlZCwgYnV0IHRoZXkgYWRkIGEgaGVhZGVyIHRoYXQgaW5mb3JtcyB0aGUg UFNBUCB0aGF0IGEgQ0EgaXMNCmF2YWlsYWJsZS4gIFRoZSBQU0FQIHRoZW4gY3JlYXRlcyBhIDMg d2F5IHZpZGVvL2F1ZGlvIGNhbGwgYW1vbmcgdGhlIFBTQVAsDQp0aGUgY2FsbGVyIGFuZCB0aGUg Q0EuICBJZiB0aGUgUFNBUCB3aXNoZXMgdG8gdXNlIGl0cyBvd24gQ0EsIGl0IGNhbiBkbw0Kc28s IGJ1dCBpdCBuZWVkcyB0byBrbm93IHRoaXMgaXMgYSBWUlMgY2FsbC4gIFRoZSBQU0FQIGRvZXNu 4oCZdCBuZWVkIHRvDQpoYW5kbGUgdmlkZW8sIHNpbmNlIGlmIGl04oCZcyBub3Qgc2VuZGluZy9y ZWNlaXZpbmcgdmlkZW8sIGl04oCZcyBhIDIgd2F5DQp2aWRlbywgMyB3YXkgYXVkaW8gY2FsbCwg YW5kIGV2ZW4gaXRzIGJyaWRnZSBkb2VzbuKAmXQgcmVhbGx5IG5lZWQgdG8gYmUgaW4NCnRoZSB2 aWRlbyBwYXRoLg0KDQpXZSBjZXJ0YWlubHkgY2FuIGhhdmUgZWNyaXQgcmV2aWV3IGRyYWZ0cyBj b21pbmcgb3V0IG9mIHRoaXMgd29yay4gIE5FTkENCmFuZCBFRU5BIHdpbGwgYWxzbyByZXZpZXcu DQoNCkkgZG9u4oCZdCBiZWxpZXZlIHRoZXJlIGlzIGEgbmVlZCB0byBoYXZlIGFuIGVudGlyZWx5 IHNlcGFyYXRlIGRvY3VtZW50IHRvDQpoYW5kbGUgdGhlIGVtZXJnZW5jeSBjYWxsIGZsb3dzLiAg V2UganVzdCBuZWVkIGFwcHJvcHJpYXRlIHJldmlldywgd2hpY2gNCknigJltIHN1cmUgd2UgY2Fu IGFycmFuZ2UuDQoNCkJyaWFuDQoNCk9uIDcvNi8xNSwgMTE6MzAgUE0sICJCZXJuYXJkIEFib2Jh IiA8YmVybmFyZF9hYm9iYUBob3RtYWlsLmNvbT4gd3JvdGU6DQoNCj5JIGFncmVlIHRoYXQgdGhl ICJkaXJlY3QiIG1vZGVsIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQgaXMgdmVyeQ0KPnByb2JsZW1h dGljLiAgT25lIG9mIHRoZSBndWlkaW5nIHByaW5jaXBsZXMgb2YgYWNjZXNzaWJpbGl0eSBpcyB0 aGF0DQo+c2VydmljZXMgbmVlZCB0byBiZSBhdmFpbGFibGUgYXMgd2lkZWx5IGFzIHBvc3NpYmxl IGdpdmVuIFBTQVANCj5jYXBhYmlsaXRpZXMuIEF0dGVtcHRpbmcgdG8gcm91dGUgVlJTIGVtZXJn ZW5jeSBjYWxscyBkaXJlY3RseSB3aWxsDQo+YWN0dWFsbHkgZHJhbWF0aWNhbGx5IHJlZHVjZSB0 aGUgYWJpbGl0eSBvZiBkaXNhYmxlZCB1c2VycyB0byByZWFjaA0KPmVtZXJnZW5jeSBzZXJ2aWNl cyBzaW5jZSB2aWRlbyBjb3VsZCBub3QgYmUgYWNjZXB0ZWQgdW50aWwgdGhlIFBTQVAgaXMNCj5l cXVpcHBlZCB0byBoYW5kbGUgaXQsIGV2ZW4gaWYgdGhlIGludGVycHJldGF0aW9uIHNlcnZpY2Ug d2VyZSBhYmxlIHRvIGRvDQo+c28sIGFuZCBhIGNhbGwgcm91dGVkIHZpYSB0aGUgaW50ZXJwcmV0 aW5nIHNlcnZpY2UgY291bGQgc3VjY2VlZCB3aXRoDQo+ZnVsbCBmdW5jdGlvbmFsaXR5Lg0KPg0K PlRoZXNlIGFyZSBleGFjdGx5IHRoZSBraW5kcyBvZiBpc3N1ZXMgdGhhdCB3b3VsZCBiZSBkZWJh dGVkIGFuZCBhZGRyZXNzZWQNCj53aXRoaW4gYSBXRyB3aXRoIGFwcHJvcHJpYXRlIFJBSSBmb2N1 cywgYnV0IHdoaWNoIGFyZSBsaWtlbHkgdG8gYmUNCj5uZWdsZWN0ZWQgaW4gYSBXRyB3aG9zZSBD aGFydGVyIGNvdmVycyBib3RoIGVtZXJnZW5jeSBzZXJ2aWNlDQo+YWNjZXNzaWJpbGl0eSBpc3N1 ZXMgYW5kIGVtYWlsIGxhbmd1YWdlIHNlbGVjdGlvbi4NCj4NCj5BdCBhIG1pbmltdW0sIEkgd291 bGQgbGlrZSB0byBzZWUgYW5vdGhlciB3b3JrIGl0ZW0gcmVsYXRpbmcgdG8gdXNlIG9mDQo+dGhl IHByb3Bvc2VkIGxhbmd1YWdlIHNwZWNpZmljYXRpb24sIGluY2x1ZGluZyBjYWxsIGZsb3dzLCB3 aXRoaW4gYSBncm91cA0KPndpdGggZW1lcmdlbmN5IHNlcnZpY2VzIG9yIFNJUCBleHBlcnRpc2Ug KHN1Y2ggYXMgRUNSSVQpLg0KPg0KPg0KPg0KPg0KPg0KPj4gT24gSnVsIDYsIDIwMTUsIGF0IDc6 MTMgUE0sIFJvc2VuLCBCcmlhbiA8QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo+DQo+Pndyb3RlOg0K Pj4gDQo+PiBXaGlsZSBJIHRoaW5rIHRoZSDigJxkaXJlY3QgbW9kZWzigJ0gaXMgYWN0dWFsbHkg dmVyeSBwcm9ibGVtYXRpYywgSSB0aGluaw0KPj4gdGhhdCBkcmFmdCBpcyBxdWl0ZSBhcHByb3By aWF0ZSBmb3IgdGhlIGJhc2ljIHB1cnBvc2Ugb2YgbWFraW5nIHN1cmUgYQ0KPj4gdHJhaW5lZCBj YWxsIHRha2VyIGdldHMgdGhlIGNhbGwuICBBbmQsIG9mIGNvdXJzZSwgaXTigJlzIGFsc28gdmVy eSB1c2VmdWwNCj4+IGZvciBnZW5lcmljIHJvdXRpbmcgb2YgY2FsbHMgZm9yIHdoaWNoIGEgVlJT IGFzIGEg4oCcdHJhbnNjb2RlcuKAnSB3b3VsZCBiZQ0KPj5hDQo+PiBtdWNoIGJldHRlciB3YXkg dG8gbWFrZSBhIGdlbmVyaWMgdmlkZW8gY2FsbCBsb29rIGRpZmZlcmVudGx5IGZyb20gYSBWUlMN Cj4+IHZpZGVvIGNhbGwsIGFuZCBpbnZva2UgcHJvcGVyIHRyZWF0bWVudC4NCj4+IA0KPj4gSXTi gJlzIGFsc28gYSBiZXR0ZXIgd2F5IHRvIGFubm91bmNlIGEgVlJTIGNhbGwgdG8gdGhlIGNhbGwg dGFrZXIuICBUb2RheSwNCj4+IHdlIGRvbuKAmXQga25vdyBpdCBmcm9tIGFueSBvdGhlciAzcmQg cGFydHkgaW5pdGlhdGVkIHZpZGVvIGNhbGwuDQo+PiANCj4+IEFzIFJhbmR5IHNheXMsIHdl4oCZ dmUgZGlzY3Vzc2VkIHRoZXNlIGlzc3VlcyB3aXRoIHRoZSBORU5BIEFjY2Vzc2liaWxpdHkNCj4+ IGdyb3VwcyBhcyB3ZWxsIGFzIHRoZSBGQ0MgYWNjZXNzaWJpbGl0eSBjb21taXR0ZWUgZm9sa3Mu ICBXZeKAmXZlIGFsc28NCj4+YmVlbg0KPj4gZGlzY3Vzc2luZyB0aGUgaXNzdWVzIHdpdGggUFNB UHMgd2hvIGhhdmUgc29tZSBtdWx0aS1saW5ndWFsIGNhbGwNCj4+dGFrZXJzLA0KPj4gYW5kIHdv dWxkIHZlcnkgbXVjaCBhcHByZWNpYXRlIGJlaW5nIGFibGUgdG8gcm91dGUgdG8gdGhlIHJpZ2h0 IHF1ZXVlLg0KPj4gQW5kLCBvZiBjb3Vyc2UsIGltcHJvdmluZyBob3cgUFNBUHMgaGFuZGxlIOKA nExhbmd1YWdlIExpbmXigJ0gc2VydmljZXMgaXMNCj4+b25lDQo+PiBvZiB0aGUgYmFzaWMgZ29h bHMgb2YgdGhpcyB3b3JrLiAgVGhlIGRpcmVjdCBtb2RlbCB3b3VsZCBtYWtlIFZSUyBsb29rDQo+ PiBleGFjdGx5IGxpa2UgTGFuZ3VhZ2UgTGluZS4NCj4+IA0KPj4gQnJpYW4NCj4+IA0KPj4gDQo+ PiANCj4+IA0KPj4gDQo+Pj4gT24gNy82LzE1LCA4OjM1IFBNLCAiUmFuZGFsbCBHZWxsZW5zIiA8 cmFuZHlAcXRpLnF1YWxjb21tLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gSGkgQmVybmFyZCwNCj4+ PiANCj4+PiBJJ2QgbGlrZSB0byBkaXNjdXNzIHlvdXIgY29uY2VybnMgYSBiaXQuICBJJ3ZlIGFk ZGVkIEJyaWFuIFJvc2VuIHRvDQo+Pj4gdGhlIGVtYWlsIGFzIGhlIGlzIGNoYWlyIG9mIHRoZSBO RyAoaTMpIGFyY2hpdGVjdHVyZSBncm91cCBpbiBORU5BLg0KPj4+IA0KPj4+IEknbSB0cnlpbmcg dG8gdW5kZXJzdGFuZCB3aHkgeW91IGJlbGlldmUgdGhhdCB0aGUgY2FsbCBmbG93IGluIDQuNQ0K Pj4+IHdvdWxkIHJlc3VsdCBpbiByZWplY3Rpb24gb2YgdGhlIHZpZGVvIHN0cmVhbSwgcmF0aGVy IHRoYW4gdGhlIFBTQVANCj4+PiBlbmdhZ2luZyBhbiBpbnRlcnByZXRhdGlvbiBzZXJ2aWNlLiAg QXMgeW91IHNheSwgd2UgYXJlIHRyeWluZyB0bw0KPj4+IG1vdmUgZnJvbSB0b2RheSdzIG1vZGVs IGluIHdoaWNoIHRoZSBjYWxsZXIgZmlyc3QgY2FsbHMgdGhlIHJlbGF5DQo+Pj4gc2VydmljZSwg YW5kIHRoZW4gdGhlIHJlbGF5IHNlcnZpY2UgYnJpZGdlcyBpbiB0aGUgUFNBUCwgdG8gYSBkaXJl Y3QNCj4+PiBtb2RlbCB3aGVyZSB0aGUgY2FsbGVyIGNhbGxzIDkxMSBkaXJlY3RseSwgYW5kIHRo ZSBQU0FQIGJyaWRnZXMgaW4NCj4+PiB0aGUgcmVsYXkgc2VydmljZS4gIE9idmlvdXNseSwgdGhl cmUgYXJlIGZ1bmRpbmcgaXNzdWVzIHRoYXQgd291bGQNCj4+PiBuZWVkIHRvIGJlIGhhbmRsZWQg aW4gb3JkZXIgZm9yIFBTQVBzIHRvIGJlIGFibGUgdG8gaW52b2tlIHJlbGF5DQo+Pj4gc2Vydmlj ZXMsIGJ1dCBib3RoIHRoZSBuZXh0LWdlbiBhbmQgYWNjZXNzaWJpbGl0eSBncm91cHMgaW4gTkVO QSB3YW50DQo+Pj4gYSBkaXJlY3QgbW9kZWwgKHdoaWNoIG9mZmVycyBtYW55IGFkdmFudGFnZXMs IGluY2x1ZGluZyBwcmlvcml0eQ0KPj4+IHRyZWF0bWVudCBhbmQgbG9jYXRpb24gZGVsaXZlcnkp LiAgVGhlIE5FTkEgUG9saWN5LUJhc2VkIFJvdXRpbmcNCj4+PiAoUEJSKSBmdW5jdGlvbmFsaXR5 IHdpdGhpbiBhbiBFU0luZXQgaGFzIHRoZSBhYmlsaXR5IHRvIHVzZSB0aGUgU0RQDQo+Pj4gd2hl biBtYWtpbmcgcm91dGluZyBkZWNpc2lvbnMgKGluIGNhc2UgUFNBUHMgaGF2ZSBjb29wZXJhdGlv bg0KPj4+IGFncmVlbWVudHMgd2hlcmUgc29tZSBQU0FQcyBoYW5kbGUgc29tZSB0eXBlcyBvZiBj YWxscyBvciBzb21lDQo+Pj4gbGFuZ3VhZ2VzIG9yIG1lZGlhKS4NCj4+PiANCj4+PiBUaGUgZHJh ZnQgYW5kIHRoZSBpc3N1ZXMgaGF2ZSBiZWVuIGRpc2N1c3NlZCB3aXRoIHRoZSBjby1jaGFpcnMg b2YNCj4+PiB0aGUgTkVOQSBhY2Nlc3NpYmlsaXR5IFdHLCBhbmQgdGhleSBhcmUgc3Ryb25nbHkg aW4gZmF2b3Igb2YgYSBkaXJlY3QNCj4+PiBtb2RlbCBmb3IgbmV4dC1nZW4uDQo+Pj4gDQo+Pj4g SW4gdGhlIFUuUy4sIGVtZXJnZW5jeSBjYWxsIHJvdXRpbmcgaXMgZmlyc3QgYnkgbG9jYXRpb24s IGFuZCB0aGVuIGJ5DQo+Pj4gbG9jYWwgcnVsZXMgKGlmIGFueSkuICBGb3IgZXhhbXBsZSwgaWYg YSBjYWxsIHJlcXVpcmVzIHRleHQsIHRoZXJlDQo+Pj4gbWlnaHQgYmUgc29tZSBQU0FQcyBpbiBh IGNvb3BlcmF0aW5nIGdyb3VwIHRoYXQgdGFrZSB0ZXh0IGNhbGxzIG9uDQo+Pj4gYmVoYWxmIG9m IG90aGVycy4gIExpa2V3aXNlIGlmIHRoZSBjYWxsIHJlcXVlc3RzIGF1ZGlvIG9yIHRleHR1YWwN Cj4+PiBTcGFuaXNoLiAgSW4gRXVyb3BlLCB2YXJpb3VzIG1vZGVscyBhcmUgdW5kZXIgZGlzY3Vz c2lvbiwgaW5jbHVkaW5nDQo+Pj4gc29tZSBpbiB3aGljaCBhIGNhbGwgbWlnaHQgYmUgcm91dGVk IHRvIGEgUFNBUCBpbiBhIGNvdW50cnkgd2hlcmUgdGhlDQo+Pj4gY2FsbGVyJ3MgbGFuZ3VhZ2Ug aXMgbmF0aXZlLiAgVGhlIGRyYWZ0IGFsbG93cyB0aGlzIGZsZXhpYmlsaXR5OiB0aGUNCj4+PiBj YWxsIGNhbiBiZSByb3V0ZWQgdG8gYSBzcGVjaWZpYyBQU0FQIChhbmQgZXZlbiBjYWxsIHRha2Vy KSBvciB0aGUNCj4+PiBQU0FQIGNhbiBicmlkZ2UgaW4gdHJhbnNsYXRpb24gb3IgcmVsYXkgc2Vy dmljZXMgYXQgdGhlIHN0YXJ0IG9mIHRoZQ0KPj4+IGNhbGwuDQo+Pj4gDQo+Pj4gQXQgNToxNSBQ TSAtMDcwMCA3LzEvMTUsIEJlcm5hcmQgQWJvYmEgd3JvdGU6DQo+Pj4gDQo+Pj4+IEkgYmVsaWV2 ZSB0aGF0IHRoaXMgQ2hhcnRlciBpcyBwb29ybHkgc3VpdGVkIHRvIGRldmVsb3BpbmcNCj4+Pj4g c29sdXRpb25zIHRvIHRoZSBwcm9ibGVtIGZhY2VkIGJ5IGRpc2FibGVkIHVzZXJzIG9mIHJlYWx0 aW1lDQo+Pj4+IGVtZXJnZW5jeSBzZXJ2aWNlcy4NCj4+Pj4gDQo+Pj4+IEluIHRoZSBjYXNlIG9m IGFjY2VzcyB0byBlbWVyZ2VuY3kgc2VydmljZXMgYnkgdGhlIGRpc2FibGVkLCB0aGUNCj4+Pj4g Z29hbCBpcyBub3QgInNlbGVjdGlvbiBvZiB0aGUgYmVzdC1maXQgbGFuZ3VhZ2UiLCBidXQgcmF0 aGVyLA0KPj4+PiByb3V0aW5nIG9mIHRoZSBjYWxsIGFuZCBtZWRpYSBzbyBhcyB0byBwdWxsIHRv Z2V0aGVyIHRoZSBzZXJ2aWNlcw0KPj4+PiBiZXN0IGZpdHRpbmcgdGhlIGVtZXJnZW5jeSBzaXR1 YXRpb24gYW5kIHRoZSBkaXNhYmlsaXRpZXMgb2YgdGhlDQo+Pj4+IGNhbGxlciwgYXMgd2VsbCBh cyB0aGUgY2FwYWJpbGl0aWVzIG9mIHRoZSBkZXZpY2UgYW5kDQo+Pj4+IGludGVybWVkaWFyaWVz IHdoaWNoIG1heSBzaXQgYmV0d2VlbiB0aGUgY2FsbGVyIGFuZCB0aGUgUFNBUC4gIE5vdA0KPj4+ PiBvbmx5IGFyZSBtZWRpYSBhbmQgbGFuZ3VhZ2UgaW50cmluc2ljYWxseSBsaW5rZWQsIGJ1dCBh bHNvLCB0aGUNCj4+Pj4gd2F5cyBpbiB3aGljaCBjYWxscyBhcmUgcm91dGVkIGlzIGluZmx1ZW5j ZWQgYW5kIGluIHNvbWUgY2FzZXMNCj4+Pj4gcHJlc2NyaWJlZCBieSByZWd1bGF0aW9uIGFuZCBu YXRpb25hbCBzdGFuZGFyZHMuDQo+Pj4+IA0KPj4+PiBTaW1wbHkgcHV0LCBkcmFmdC1nZWxsZW5z LXNsaW0tbmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UgbGFja3MNCj4+Pj4gYXBwcm9wcmlhdGUg Y29uc2lkZXJhdGlvbiBvZiB0aGUgcHJvYmxlbSBjb250ZXh0LiAgU3BlY2lmeWluZyBpdCBhcw0K Pj4+PiB0aGUgc3RhcnRpbmcgcG9pbnQgaXMgdGhlcmVmb3JlIGluYXBwcm9wcmlhdGUuIEFzIGFu IGV4YW1wbGUsIHRvZGF5DQo+Pj4+IHRoZSBjYWxsIGZsb3cgZGVzY3JpYmVkIGluIFNlY3Rpb24g NC41IHdvdWxkIG1vc3QgbGlrZWx5IHJlc3VsdCBpbg0KPj4+PiByZWplY3Rpb24gb2YgdGhlIHZp ZGVvIHBvcnRpb24gb2YgdGhlIGNhbGwgYnkgdGhlIFBTQVAsIGxlYXZpbmcgdGhlDQo+Pj4+IGRp c3BhdGNoZXIgd2l0aCBubyBtZWFucyBvZiBjb21tdW5pY2F0aW5nIHdpdGggdGhlIGhlYXJpbmct aW1wYWlyZWQNCj4+Pj4gY2FsbGVyLCB0aHVzIGxlYXZpbmcgdGhlIGNhbGxlciB3b3JzZSBvZmYg dGhhbiB0aGV5IGFyZSB0b2RheQ0KPj4+PiBhdHRlbXB0aW5nIHRvIG1ha2UgYW4gZW1lcmdlbmN5 IGNhbGwgd2l0aGluIHRoZSAoY3VtYmVyc29tZSBhbmQNCj4+Pj4gZXJyb3IvZGVsYXktcHJvbmUp IFZpZGVvIFJlbGF5IFNlcnZpY2UuICAgQSBmdWxsZXIgY29uc2lkZXJhdGlvbiBvZg0KPj4+PiB0 aGUgcHJvYmxlbSBjb250ZXh0IHdvdWxkIGludm9sdmUgY29uc2lkZXJhdGlvbiBvZiBjdXJyZW50 DQo+Pj4+IG9wZXJhdGlvbiBvZiByZWxheSBzZXJ2aWNlcyBhbmQgcHJvcG9zYWxzIGZvciB0aGVp ciBldm9sdXRpb24uDQo+Pj4+IEF0dGVtcHRpbmcgdG8gZGV2ZWxvcCB0aGlzIHByb2JsZW0gY29u dGV4dCB3aXRoaW4gYSBXRyB0aGF0IGlzDQo+Pj4+IGFsc28gYXR0ZW1wdGluZyB0byBkZWFsIHdp dGggbGFuZ3VhZ2Utc2VsZWN0aW9uIGluIGVtYWlsIHdvdWxkIGJlDQo+Pj4+IGZydXN0cmF0aW5n IGF0IGJlc3QuDQo+Pj4+IA0KPj4+PiBBIHNlbnNpYmxlIENoYXJ0ZXIgd291bGQgYWxzbyBwcm9i YWJseSBpbmNsdWRlIGxpYWlzb25zIHdpdGgNCj4+Pj4gZGlzYWJpbGl0eSByaWdodHMgb3JnYW5p emF0aW9ucywgZ3JvdXBzIHNwZWNpZnlpbmcgdGhlIG9wZXJhdGlvbiBvZg0KPj4+PiByZWxheSBz ZXJ2aWNlcywgYW5kIGdyb3VwcyBjb25zaWRlcmluZyBuZXh0IHN0ZXBzIGZvciBhY2Nlc3MgdG8N Cj4+Pj4gZW1lcmdlbmN5IHNlcnZpY2VzLg0KPj4+PiANCj4+Pj4+IEZyb206IGllc2dAaWV0Zi5v cmcNCj4+Pj4+IFRvOiBuZXctd29ya0BpZXRmLm9yZw0KPj4+Pj4gRGF0ZTogRnJpLCAyNiBKdW4g MjAxNSAwODozNjowNSAtMDcwMA0KPj4+Pj4gU3ViamVjdDogW25ldy13b3JrXSBXRyBSZXZpZXc6 IFNlbGVjdGlvbiBvZiBMYW5ndWFnZSBmb3IgSW50ZXJuZXQNCj4+Pj4+IE1lZGlhIChzbGltKQ0K Pj4+Pj4gDQo+Pj4+PiBBIG5ldyBJRVRGIHdvcmtpbmcgZ3JvdXAgaGFzIGJlZW4gcHJvcG9zZWQg aW4gdGhlIEFwcGxpY2F0aW9ucyBhbmQNCj4+Pj4+IFJlYWwtVGltZSBBcmVhLiBUaGUgSUVTRyBo YXMgbm90IG1hZGUgYW55IGRldGVybWluYXRpb24geWV0LiBUaGUNCj4+Pj4+IGZvbGxvd2luZyBk cmFmdCBjaGFydGVyIHdhcyBzdWJtaXR0ZWQsIGFuZCBpcyBwcm92aWRlZCBmb3INCj4+Pj4+IGlu Zm9ybWF0aW9uYWwNCj4+Pj4+IHB1cnBvc2VzIG9ubHkuIFBsZWFzZSBzZW5kIHlvdXIgY29tbWVu dHMgdG8gdGhlIElFU0cgbWFpbGluZyBsaXN0DQo+Pj4+PiAoaWVzZw0KPj4+Pj4gYXQgaWV0Zi5v cmcpIGJ5IDIwMTUtMDctMDYuDQo+Pj4+PiANCj4+Pj4+IFNlbGVjdGlvbiBvZiBMYW5ndWFnZSBm b3IgSW50ZXJuZXQgTWVkaWEgKHNsaW0pDQo+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+IEN1cnJlbnQgU3RhdHVzOiBQcm9wb3NlZCBX Rw0KPj4+Pj4gDQo+Pj4+PiBBc3NpZ25lZCBBcmVhIERpcmVjdG9yOg0KPj4+Pj4gQmFycnkgTGVp YmEgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPg0KPj4+Pj4gDQo+Pj4+PiBNYWlsaW5nIGxpc3QN Cj4+Pj4+IEFkZHJlc3M6IHNsaW1AaWV0Zi5vcmcNCj4+Pj4+IFRvIFN1YnNjcmliZTogaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zbGltDQo+Pj4+PiBBcmNoaXZlOiBodHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL3NsaW0vDQo+Pj4+PiANCj4+Pj4+ IENoYXJ0ZXI6DQo+Pj4+PiANCj4+Pj4+IERlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6DQo+ Pj4+PiANCj4+Pj4+IEEgbXV0dWFsbHkgY29tcHJlaGVuc2libGUgbGFuZ3VhZ2UgaXMgaGVscGZ1 bCBmb3IgaHVtYW4NCj4+Pj4+Y29tbXVuaWNhdGlvbi4NCj4+Pj4+IFRoaXMgaXMgdHJ1ZSBhY3Jv c3MgYSByYW5nZSBvZiBjaXJjdW1zdGFuY2VzIGFuZCBlbnZpcm9ubWVudHMuIEluDQo+Pj4+PiBn ZW5lcmFsLCB0aGUgcHJvYmxlbSBpcyBtb3N0IGFjdXRlIGluIHNpdHVhdGlvbnMgd2hlcmUgdGhl cmUgaXMgbm90IGENCj4+Pj4+IGNsZWFyIGNob2ljZSBmb3IgYSBzaW5nbGUgbGFuZ3VhZ2UsIHN1 Y2ggYXMgZW52aXJvbm1lbnRzIGxhY2tpbmcNCj4+Pj4+IGNvbnRleHR1YWwgb3Igb3V0LW9mLWJh bmQgaW5mb3JtYXRpb24gcmVnYXJkaW5nIHRoZSBpZGVudGl0eSBvZiB0aGUNCj4+Pj4+IHBhcnRp ZXMgYW5kIHRoZSBsYW5ndWFnZSB0byBiZSB1c2VkLg0KPj4+Pj4gDQo+Pj4+PiBUaGUgZ3JvdXAg d2lsbCBhZGRyZXNzIHR3byBzcGVjaWZpYyBjYXNlcyB0aGF0IG1vc3QgdXJnZW50bHkgbmVlZCBh DQo+Pj4+PiB0ZWNobmljYWwgc29sdXRpb246IE9uZSBwcm9ibGVtIHNwYWNlIGlzIG5vbi1yZWFs LXRpbWUgY29tbXVuaWNhdGlvbiwNCj4+Pj4+IHNwZWNpZmljYWxseSBlbWFpbCBmb3Igb25lLXRv LW1hbnkgb3Igd2hlcmUgdGhlIHNldCBvZiByZWNpcGllbnRzIGlzDQo+Pj4+PiBkeW5hbWljIG9y IGRpZmZlcmVudCByZWNpcGllbnRzIHJlcXVpcmUgZGlmZmVyZW50IGxhbmd1YWdlczsgdGhlDQo+ Pj4+PiBvdGhlciBpcw0KPj4+Pj4gcmVhbC10aW1lIGNvbW11bmljYXRpb24sIHNwZWNpZmljYWxs eSBlbWVyZ2VuY3kgY2FsbGluZywgcHJlZmVyYWJseQ0KPj4+Pj4gYWxzbw0KPj4+Pj4gdXNlZnVs IGZvciBvdGhlciBjYXNlcyB3aGVyZSB0aGUgcGFydGllcyBtYXkgbm90IGtub3cgZWFjaCBvdGhl cg0KPj4+Pj4gcGVyc29uYWxseSBvciB3aGVyZSBvbmUgcGFydHkgd2lzaGVzIHRvIGFjY29tbW9k YXRlIHBlb3BsZSB3aXRoDQo+Pj4+PiB2YXJ5aW5nDQo+Pj4+PiBsYW5ndWFnZSBhbmQgbWVkaWEg bmVlZHMuDQo+Pj4+PiANCj4+Pj4+IEluIHRoZSByZWFsLXRpbWUgY29tbXVuaWNhdGlvbiBjYXNl LCBsYW5ndWFnZSBhbmQgbWVkaWEgYXJlDQo+Pj4+PiBpbnRyaW5zaWNhbGx5DQo+Pj4+PiBsaW5r ZWQsIGZvciBleGFtcGxlLCBzaWduZWQgbGFuZ3VhZ2VzIHJlcXVpcmUgYSB2aWRlbyBtZWRpYS4N Cj4+Pj4+IA0KPj4+Pj4gV2hpbGUgdGhlIHR3byB1c2UgY2FzZXMgYXJlIGluIGRpZmZlcmVudCBj b250ZXh0cyAocmVhbCB0aW1lIGFuZA0KPj4+Pj4gbm9uLXJlYWwtdGltZSksIHRoZSBmdW5kYW1l bnRhbCBnb2FsIGlzIHRoZSBzYW1lOiB0byBlbmFibGUgc2VsZWN0aW9uDQo+Pj4+PiBvZg0KPj4+ Pj4gdGhlIGJlc3QtZml0IGxhbmd1YWdlKHMpIGZvciBhIHNwZWNpZmljIHNpdHVhdGlvbi4gU29t ZSBvZiB0aGUNCj4+Pj4+ZGV0YWlscw0KPj4+Pj4gd2lsbCBhbHNvIGJlIGluIGNvbW1vbiBhY3Jv c3MgdGhlIGNhc2VzLCBlLmcuLCB0aGUgbGFuZ3VhZ2UgdGFncy4NCj4+Pj4+IEhhdmluZw0KPj4+ Pj4gYSBzaW5nbGUgV0cgYWRkcmVzcyBib3RoIGNhc2VzIG1ha2VzIGl0IGNsZWFyIHRoYXQgdGhl c2UgYXJlIHR3bw0KPj4+Pj4gYXNwZWN0cw0KPj4+Pj4gb2YgdGhlIHNhbWUgYmFzaWMgcHJvYmxl bS4gQSBzaW5nbGUgV0cgYWxzbyBtYWtlcyBpdCBlYXNpZXIgdG8NCj4+Pj4+IG1heGltaXplDQo+ Pj4+PiBzaW1pbGFyaXRpZXMgYW5kIGF2b2lkIHVubmVjZXNzYXJ5IGZyYWdtZW50YXRpb24gb2Yg dGhlIHNvbHV0aW9ucywNCj4+Pj4+YW5kDQo+Pj4+PiBmYWNpbGl0YXRlcyBicm9hZGVyIHJldmll dy4NCj4+Pj4+IA0KPj4+Pj4gVGhlIGdyb3VwIHdpbGwgcHJvZHVjZSB0d28gZG9jdW1lbnRzLCBv bmUgZm9yIGVtYWlsLCBhbmQgb25lIGZvcg0KPj4+Pj4gcmVhbC10aW1lIGNvbW11bmljYXRpb25z Lg0KPj4+Pj4gDQo+Pj4+PiBJbiB0aGUgZW1haWwgY2FzZSwgdGhlIGdyb3VwIHdpbGwgZGV0ZXJt aW5lIGEgTUlNRSBiYXNlZCBzb2x1dGlvbg0KPj4+Pj50aGF0DQo+Pj4+PiBlbmFibGVzIGEgc2lu Z2xlIGVtYWlsIG1lc3NhZ2UgdG8gY29udGFpbiBtdWx0aXBsZSBsYW5ndWFnZSB2ZXJzaW9ucw0K Pj4+Pj4gb2YNCj4+Pj4+IHRoZSBjb250ZW50LCB3aXRoIHByb3Zpc2lvbnMgdG8gaGVscCBjbGll bnRzIHNlbGVjdCBhIGJlc3QgZml0DQo+Pj4+PiB2ZXJzaW9uLg0KPj4+Pj4gDQo+Pj4+PiBJbiB0 aGUgcmVhbC10aW1lIGNvbW11bmljYXRpb24gY2FzZSwgdGhlIGdyb3VwIHdpbGwgcHJvZHVjZSBh DQo+Pj4+PiBzcGVjaWZpY2F0aW9uIGJhc2VkIG9uIGRyYWZ0LWdlbGxlbnMtc2xpbS1uZWdvdGlh dGluZy1odW1hbi1sYW5ndWFnZSwNCj4+Pj4+IGVuYWJsaW5nIG5lZ290aWF0aW9uIG9mIGEgaHVt YW4gbGFuZ3VhZ2UgcGVyIG1lZGlhIHN0cmVhbS4gVGhlDQo+Pj4+PiBzcGVjaWZpY2F0aW9uIG11 c3QgYmUgc3VpdGFibGUgZm9yIHVzZSBpbiBlbWVyZ2VuY3kgY29tbXVuaWNhdGlvbnMgYXMNCj4+ Pj4+IHNwZWNpZmllZCBpbiBSRkMgNjQ0MyBhbmQgUkZDIDY4ODEgKHdoaWNoIHVzZSBTSVAgYW5k IFNEUCB0bw0KPj4+Pj5uZWdvdGlhdGUNCj4+Pj4+IG1lZGlhKTsgaXQgaXMgZGVzaXJhYmxlIHRv IGFsc28gYmUgc3VpdGFibGUgZm9yIHVzZSBpbiBub24tZW1lcmdlbmN5DQo+Pj4+PiByZWFsLXRp bWUgY29tbXVuaWNhdGlvbnMgdGhhdCBzaGFyZSB0aGUgc2FtZSBjYWxsIHNldC11cCBhbmQgbWVk aWENCj4+Pj4+IG5lZ290aWF0aW9uIHByb3RvY29scy4gVGhlIG1lY2hhbmlzbSB3aWxsIHBlcm1p dCB0aGUgY2FsbGVyJ3MgbWVkaWENCj4+Pj4+IGFuZA0KPj4+Pj4gbGFuZ3VhZ2UgbmVlZHMgYW5k IHByZWZlcmVuY2VzIHRvIGJlIG1hdGNoZWQgYWdhaW5zdCB3aGF0IHRoZSBjYWxsZWQNCj4+Pj4+ IHBhcnR5IGlzIGFibGUgdG8gcHJvdmlkZS4gVGhlIG1lY2hhbmlzbSB3aWxsIHBlcm1pdCByZXNv dXJjZXMgKGUuZy4sDQo+Pj4+PiB0cmFuc2xhdGlvbiwgcmVsYXksIG1lZGlhKSB0byBiZSBhbGxv Y2F0ZWQgb3IgZW5nYWdlZCBhcyBlYXJseSBhcw0KPj4+Pj4gcG9zc2libGUgaW4gdGhlIGNhbGwg c2V0LXVwIG9yIGZvciB0aGUgY2FsbCB0byBiZSByb3V0ZWQgb3IgaGFuZGxlZA0KPj4+Pj4gc3Bl Y2lhbGx5IChlLmcuLCByb3V0ZWQgdG8gYSByZXNvdXJjZSBhYmxlIHRvIHByb3ZpZGUgYSBuZWVk ZWQNCj4+Pj4+IGxhbmd1YWdlDQo+Pj4+PiBhbmQvb3IgbWVkaWEpLiBBbHRlcm5hdGl2ZXMgc3Vj aCBhcyBkb2luZyB0aGUgbmVnb3RpYXRpb24gaW4gU0lQIGhhdmUNCj4+Pj4+IGJlZW4gdGhvcm91 Z2hseSBleHBsb3JlZCBpbiB0aGUgcGFzdCBhbmQgYXJlIG91dCBvZiBzY29wZSAoYWx0aG91Z2gN Cj4+Pj4+IHRoZQ0KPj4+Pj4gc2NvcGUgbWlnaHQgYmUgZXh0ZW5kZWQgYWZ0ZXIgdGhlIFNEUCBt ZWNoYW5pc20gaGFzIGJlZW4gYWR2YW5jZWQpLg0KPj4+Pj4gDQo+Pj4+PiBCeSBhZGRpbmcgbGFu Z3VhZ2UgdG8gdGhlIGV4aXN0aW5nIG1lZGlhIG5lZ290aWF0aW9uIG1lY2hhbmlzbSBhcw0KPj4+ Pj4gdXNlZCBpbg0KPj4+Pj4gUkZDIDY0NDMgYW5kIFJGQyA2ODgxLCB0aGUgZ3JvdXAgY2FuIG1l ZXQgdGhlIGJhc2ljIHVzZSBjYXNlcyB3aXRoDQo+Pj4+PiBtaW5pbWFsIGFkZGVkIGNvbXBsZXhp dHkgYW5kIGJlIGFibGUgdG8gZW5oYW5jZSBsYXRlciBmb3IgYWRkaXRpb25hbA0KPj4+Pj4gdXNl DQo+Pj4+PiBjYXNlcyBhcyBuZWVkZWQuDQo+Pj4+PiANCj4+Pj4+IE1pbGVzdG9uZXM6DQo+Pj4+ PiBPY3QgMjAxNSAtIFN1Ym1pdCAiTXVsdGlwbGUgTGFuZ3VhZ2UgQ29udGVudCBUeXBlIiB0byB0 aGUgSUVTRyAoYmFzZWQNCj4+Pj4+IG9uIGRyYWZ0LXRvbWtpbnNvbi1zbGltLW11bHRpbGFuZ2Nv bnRlbnQpDQo+Pj4+PiBGZWIgMjAxNiAtIFN1Ym1pdCAiTmVnb3RpYXRpbmcgSHVtYW4gTGFuZ3Vh Z2UgaW4gUmVhbC1UaW1lDQo+Pj4+PiBDb21tdW5pY2F0aW9ucyIgdG8gdGhlIElFU0cgKGJhc2Vk IG9uDQo+Pj4+PiBkcmFmdC1nZWxsZW5zLXNsaW0tbmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2Up DQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+Pj4+IG5ldy13b3JrIG1haWxpbmcgbGlzdA0KPj4+Pj4gbmV3LXdv cmtAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV3LXdvcmsNCj4+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gLS0g DQo+Pj4gUmFuZGFsbCBHZWxsZW5zDQo+Pj4gT3BpbmlvbnMgYXJlIHBlcnNvbmFsOyAgICBmYWN0 cyBhcmUgc3VzcGVjdDsgICAgSSBzcGVhayBmb3IgbXlzZWxmIG9ubHkNCj4+PiAtLS0tLS0tLS0t LS0tLSBSYW5kb21seSBzZWxlY3RlZCB0YWc6IC0tLS0tLS0tLS0tLS0tLQ0KPj4+IEp1c3QgYmVj YXVzZSB5b3UgZG8gbm90IHRha2UgYW4gaW50ZXJlc3QgaW4gcG9saXRpY3MgZG9lc24ndCBtZWFu DQo+Pj4gcG9saXRpY3Mgd29uJ3QgdGFrZSBhbmQgaW50ZXJlc3QgaW4geW91LiAgLS1QZXJpY2xl cyAoNDk1LTQyNSBCQykNCj4+IA0KDQo= From nobody Tue Jul 7 07:06:13 2015 Return-Path: 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 3508D1AC3F5 for ; Tue, 7 Jul 2015 07:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 9nBariG_1vop for ; Tue, 7 Jul 2015 07:06:07 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22481AC3E1 for ; Tue, 7 Jul 2015 07:06:07 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-09v.sys.comcast.net with comcast id pS5R1q00C2XD5SV01S66kV; Tue, 07 Jul 2015 14:06:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-20v.sys.comcast.net with comcast id pS651q00h3Ge9ey01S66uE; Tue, 07 Jul 2015 14:06:06 +0000 Message-ID: <559BDCCC.5050507@alum.mit.edu> Date: Tue, 07 Jul 2015 10:06:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: ecrit@ietf.org References: <20150626153605.18943.13946.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1436277966; bh=u8lLHctU/B80oTLJWhscdXCFN9AIWU+YREB0CFuk+Xo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KjT6GHYs7o3RbiyU0eEpCLJ8IbdUfvGJ4b/sKnQ68zdS9LMMIRrkO/jxDga7TtROO miDVwrmIzfS3mCGGfynwXc9oojdsB902U2cNYRvGHBcYKCssTeskyIBqAW0ty5uRl7 E1xtCPer5fvkDrzzlkPlxSmZOfawIyJlSYe1AIv1TxjBFligIHT5qwTMcyXcuD8V6p 0S6GikouRp7Bxa4/agMXlOtbmZd3rjF9aN9Asgta0ctK0GdJCzmUuP0Op3boscqiax w0QtNrl3m5DyRqxAlWpP9kLWBqSVkyqOpk6muxjh7cmJtXvsyhRqmSNSda0g7R2k/D yGaAxnFd8ZU1Q== Archived-At: Subject: Re: [Ecrit] [new-work] WG Review: Selection of Language for Internet Media (slim) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 14:06:11 -0000 On 7/6/15 11:30 PM, Bernard Aboba wrote: > I agree that the "direct" model described in the draft is very problematic. One of the guiding principles of accessibility is that services need to be available as widely as possible given PSAP capabilities. Attempting to route VRS emergency calls directly will actually dramatically reduce the ability of disabled users to reach emergency services since video could not be accepted until the PSAP is equipped to handle it, even if the interpretation service were able to do so, and a call routed via the interpreting service could succeed with full functionality. > > These are exactly the kinds of issues that would be debated and addressed within a WG with appropriate RAI focus, but which are likely to be neglected in a WG whose Charter covers both emergency service accessibility issues and email language selection. > > At a minimum, I would like to see another work item relating to use of the proposed language specification, including call flows, within a group with emergency services or SIP expertise (such as ECRIT). +1 (But did you mean to sent this to ecrit, or slim?) Thanks, Paul >> On Jul 6, 2015, at 7:13 PM, Rosen, Brian wrote: >> >> While I think the “direct model†is actually very problematic, I think >> that draft is quite appropriate for the basic purpose of making sure a >> trained call taker gets the call. And, of course, it’s also very useful >> for generic routing of calls for which a VRS as a “transcoder†would be a >> much better way to make a generic video call look differently from a VRS >> video call, and invoke proper treatment. >> >> It’s also a better way to announce a VRS call to the call taker. Today, >> we don’t know it from any other 3rd party initiated video call. >> >> As Randy says, we’ve discussed these issues with the NENA Accessibility >> groups as well as the FCC accessibility committee folks. We’ve also been >> discussing the issues with PSAPs who have some multi-lingual call takers, >> and would very much appreciate being able to route to the right queue. >> And, of course, improving how PSAPs handle “Language Line†services is one >> of the basic goals of this work. The direct model would make VRS look >> exactly like Language Line. >> >> Brian >> >> >> >> >> >>> On 7/6/15, 8:35 PM, "Randall Gellens" wrote: >>> >>> Hi Bernard, >>> >>> I'd like to discuss your concerns a bit. I've added Brian Rosen to >>> the email as he is chair of the NG (i3) architecture group in NENA. >>> >>> I'm trying to understand why you believe that the call flow in 4.5 >>> would result in rejection of the video stream, rather than the PSAP >>> engaging an interpretation service. As you say, we are trying to >>> move from today's model in which the caller first calls the relay >>> service, and then the relay service bridges in the PSAP, to a direct >>> model where the caller calls 911 directly, and the PSAP bridges in >>> the relay service. Obviously, there are funding issues that would >>> need to be handled in order for PSAPs to be able to invoke relay >>> services, but both the next-gen and accessibility groups in NENA want >>> a direct model (which offers many advantages, including priority >>> treatment and location delivery). The NENA Policy-Based Routing >>> (PBR) functionality within an ESInet has the ability to use the SDP >>> when making routing decisions (in case PSAPs have cooperation >>> agreements where some PSAPs handle some types of calls or some >>> languages or media). >>> >>> The draft and the issues have been discussed with the co-chairs of >>> the NENA accessibility WG, and they are strongly in favor of a direct >>> model for next-gen. >>> >>> In the U.S., emergency call routing is first by location, and then by >>> local rules (if any). For example, if a call requires text, there >>> might be some PSAPs in a cooperating group that take text calls on >>> behalf of others. Likewise if the call requests audio or textual >>> Spanish. In Europe, various models are under discussion, including >>> some in which a call might be routed to a PSAP in a country where the >>> caller's language is native. The draft allows this flexibility: the >>> call can be routed to a specific PSAP (and even call taker) or the >>> PSAP can bridge in translation or relay services at the start of the >>> call. >>> >>> At 5:15 PM -0700 7/1/15, Bernard Aboba wrote: >>> >>>> I believe that this Charter is poorly suited to developing >>>> solutions to the problem faced by disabled users of realtime >>>> emergency services. >>>> >>>> In the case of access to emergency services by the disabled, the >>>> goal is not "selection of the best-fit language", but rather, >>>> routing of the call and media so as to pull together the services >>>> best fitting the emergency situation and the disabilities of the >>>> caller, as well as the capabilities of the device and >>>> intermediaries which may sit between the caller and the PSAP. Not >>>> only are media and language intrinsically linked, but also, the >>>> ways in which calls are routed is influenced and in some cases >>>> prescribed by regulation and national standards. >>>> >>>> Simply put, draft-gellens-slim-negotiating-human-language lacks >>>> appropriate consideration of the problem context. Specifying it as >>>> the starting point is therefore inappropriate. As an example, today >>>> the call flow described in Section 4.5 would most likely result in >>>> rejection of the video portion of the call by the PSAP, leaving the >>>> dispatcher with no means of communicating with the hearing-impaired >>>> caller, thus leaving the caller worse off than they are today >>>> attempting to make an emergency call within the (cumbersome and >>>> error/delay-prone) Video Relay Service. A fuller consideration of >>>> the problem context would involve consideration of current >>>> operation of relay services and proposals for their evolution. >>>> Attempting to develop this problem context within a WG that is >>>> also attempting to deal with language-selection in email would be >>>> frustrating at best. >>>> >>>> A sensible Charter would also probably include liaisons with >>>> disability rights organizations, groups specifying the operation of >>>> relay services, and groups considering next steps for access to >>>> emergency services. >>>> >>>>> From: iesg@ietf.org >>>>> To: new-work@ietf.org >>>>> Date: Fri, 26 Jun 2015 08:36:05 -0700 >>>>> Subject: [new-work] WG Review: Selection of Language for Internet >>>>> Media (slim) >>>>> >>>>> A new IETF working group has been proposed in the Applications and >>>>> Real-Time Area. The IESG has not made any determination yet. The >>>>> following draft charter was submitted, and is provided for >>>>> informational >>>>> purposes only. Please send your comments to the IESG mailing list >>>>> (iesg >>>>> at ietf.org) by 2015-07-06. >>>>> >>>>> Selection of Language for Internet Media (slim) >>>>> ------------------------------------------------ >>>>> Current Status: Proposed WG >>>>> >>>>> Assigned Area Director: >>>>> Barry Leiba >>>>> >>>>> Mailing list >>>>> Address: slim@ietf.org >>>>> To Subscribe: https://www.ietf.org/mailman/listinfo/slim >>>>> Archive: https://mailarchive.ietf.org/arch/browse/slim/ >>>>> >>>>> Charter: >>>>> >>>>> Description of Working Group: >>>>> >>>>> A mutually comprehensible language is helpful for human communication. >>>>> This is true across a range of circumstances and environments. In >>>>> general, the problem is most acute in situations where there is not a >>>>> clear choice for a single language, such as environments lacking >>>>> contextual or out-of-band information regarding the identity of the >>>>> parties and the language to be used. >>>>> >>>>> The group will address two specific cases that most urgently need a >>>>> technical solution: One problem space is non-real-time communication, >>>>> specifically email for one-to-many or where the set of recipients is >>>>> dynamic or different recipients require different languages; the >>>>> other is >>>>> real-time communication, specifically emergency calling, preferably >>>>> also >>>>> useful for other cases where the parties may not know each other >>>>> personally or where one party wishes to accommodate people with >>>>> varying >>>>> language and media needs. >>>>> >>>>> In the real-time communication case, language and media are >>>>> intrinsically >>>>> linked, for example, signed languages require a video media. >>>>> >>>>> While the two use cases are in different contexts (real time and >>>>> non-real-time), the fundamental goal is the same: to enable selection >>>>> of >>>>> the best-fit language(s) for a specific situation. Some of the details >>>>> will also be in common across the cases, e.g., the language tags. >>>>> Having >>>>> a single WG address both cases makes it clear that these are two >>>>> aspects >>>>> of the same basic problem. A single WG also makes it easier to >>>>> maximize >>>>> similarities and avoid unnecessary fragmentation of the solutions, and >>>>> facilitates broader review. >>>>> >>>>> The group will produce two documents, one for email, and one for >>>>> real-time communications. >>>>> >>>>> In the email case, the group will determine a MIME based solution that >>>>> enables a single email message to contain multiple language versions >>>>> of >>>>> the content, with provisions to help clients select a best fit >>>>> version. >>>>> >>>>> In the real-time communication case, the group will produce a >>>>> specification based on draft-gellens-slim-negotiating-human-language, >>>>> enabling negotiation of a human language per media stream. The >>>>> specification must be suitable for use in emergency communications as >>>>> specified in RFC 6443 and RFC 6881 (which use SIP and SDP to negotiate >>>>> media); it is desirable to also be suitable for use in non-emergency >>>>> real-time communications that share the same call set-up and media >>>>> negotiation protocols. The mechanism will permit the caller's media >>>>> and >>>>> language needs and preferences to be matched against what the called >>>>> party is able to provide. The mechanism will permit resources (e.g., >>>>> translation, relay, media) to be allocated or engaged as early as >>>>> possible in the call set-up or for the call to be routed or handled >>>>> specially (e.g., routed to a resource able to provide a needed >>>>> language >>>>> and/or media). Alternatives such as doing the negotiation in SIP have >>>>> been thoroughly explored in the past and are out of scope (although >>>>> the >>>>> scope might be extended after the SDP mechanism has been advanced). >>>>> >>>>> By adding language to the existing media negotiation mechanism as >>>>> used in >>>>> RFC 6443 and RFC 6881, the group can meet the basic use cases with >>>>> minimal added complexity and be able to enhance later for additional >>>>> use >>>>> cases as needed. >>>>> >>>>> Milestones: >>>>> Oct 2015 - Submit "Multiple Language Content Type" to the IESG (based >>>>> on draft-tomkinson-slim-multilangcontent) >>>>> Feb 2016 - Submit "Negotiating Human Language in Real-Time >>>>> Communications" to the IESG (based on >>>>> draft-gellens-slim-negotiating-human-language) >>>>> >>>>> >>>>> _______________________________________________ >>>>> new-work mailing list >>>>> new-work@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/new-work >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself only >>> -------------- Randomly selected tag: --------------- >>> Just because you do not take an interest in politics doesn't mean >>> politics won't take and interest in you. --Pericles (495-425 BC) >> > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From nobody Tue Jul 7 08:00:11 2015 Return-Path: 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 402741ACD79 for ; Tue, 7 Jul 2015 08:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 5SqrNjuIoNpX for ; Tue, 7 Jul 2015 08:00:07 -0700 (PDT) Received: from bin-vsp-out-04.atm.binero.net (vsp-authed02.binero.net [195.74.38.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09AD51ACD59 for ; Tue, 7 Jul 2015 08:00:04 -0700 (PDT) X-Halon-ID: d451fb72-24b8-11e5-b1dc-005056917c0c Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.64.158.13]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Tue, 7 Jul 2015 16:59:55 +0200 (CEST) Message-ID: <559BE96D.2030502@omnitor.se> Date: Tue, 07 Jul 2015 16:59:57 +0200 From: =?UTF-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Rosen, Brian" , Bernard Aboba References: <20150626153605.18943.13946.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: slim@ietf.org, Randall Gellens , "ecrit@ietf.org" Subject: Re: [Ecrit] [new-work] WG Review: Selection of Language for Internet Media (slim) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 15:00:10 -0000 I deleted ietf and iesg from the addresses and added slim. But you are right that this is a general sip topic as well. Just tell where we shall continue the discussion. About work items: I think slim can continue to create its planned media and modality indications. But work is needed on the routing mechanisms using SLIM and other indications to decide on connection of users and optionally assisting services (such as relay). It is better if the mechanisms are general, and not emergency service specific. One reason is that users will then have much higher tendency to keep their preference settings in order. Another reason is that large parts of the mechanisms will be used and verified to work. The emergency service specific mechanisms have the risk of not being thoroughly tested for every kind of terminal/service provider/modality combination. IN ETSI STF 489 we are right now intensively discussing the topics in this thread, and have a need to come to conclusions on realistic mechanisms that optimise user benefits in the emergency call scenarios. One risk we have seen is what Brian also describes. A call with e.g. total conversation being routed to an ESInet entry of a country at the moment only supporting speech in the PSAPs. If it is a call requiring sign language translation, it is true that the ESInet or PSAP bridge could support video and real-time text even if no PSAP in that network does so. Then we can get a proper video relay invoked and accept to have the communication with the PSAP in speech with the interpreter. But how can we handle the situation that there is a gap in NG112 implementation. The user is in a country still on PSTN for 112. The search for an ESInet entry for that country will fail and the SIP service provider need to convert to PSTN emergency calling. Then it can not be expected that the 112 network can bridge the multimedia call. It seems to me that for that case, the user terminal or sip service provider needs to have the bridge for that case. That means that we end up with recommendations to have bridges in various places to be able to handle the different call scenarios optimally. Do you agree? I just sent to SLIM also the view that SIP media and language tags as they are defined today can be used to detect need for sign language support ( as indicated in RFC 6443), while the asymmetric needs of deaf-blind communication or hard-of hearing communication will require slim-style indications and yet relay service users of speech-to-speech and captioned telephony services cannot describe their needs with the current proposed coding of slim, and woulld likely be better off to have a possibility to just request an assisting service by a URI and a sip operation. Thus slim is only part of the solution. It would be good to have somewhere to discuss the whole picture and set slim and the other mechanisms in their context. Where? Gunnar Rosen, Brian skrev den 2015-07-07 14:51: > But the draft doesn’t suggest that the direct model should replace the > current emergency call routing, it merely allows new capability. If there > is any language you find that makes it seem like direct routing should be > preferred over the current location based routing, we can address that. > > On your specific point about not being able to deal with non-video > equipped PSAPs, we have plenty of mechanisms available to readily > accommodate that situation. Devices are required to follow existing > practice of forwarding calls to their normal outbound proxy, and this > draft doesn’t change that at all. What happens after that is confined to > what the services that provide routing for VRS, and we can handle location > sensitive handling of such calls. All 9-1-1 calls are “direct†routed, in > that they route to the outbound proxy, which routes based on the LoST > query result, and that is not media sensitive. That delivers the call to > the right inbound proxy server, which then is able to route based on > media, if desired. > > The way we handle VRS, and still get calls routed by the location of the > caller is to have the VRS service route the call like any other 9-1-1 call > would be routed, but they add a header that informs the PSAP that a CA is > available. The PSAP then creates a 3 way video/audio call among the PSAP, > the caller and the CA. If the PSAP wishes to use its own CA, it can do > so, but it needs to know this is a VRS call. The PSAP doesn’t need to > handle video, since if it’s not sending/receiving video, it’s a 2 way > video, 3 way audio call, and even its bridge doesn’t really need to be in > the video path. > > We certainly can have ecrit review drafts coming out of this work. NENA > and EENA will also review. > > I don’t believe there is a need to have an entirely separate document to > handle the emergency call flows. We just need appropriate review, which > I’m sure we can arrange. > > Brian > > On 7/6/15, 11:30 PM, "Bernard Aboba" wrote: > >> I agree that the "direct" model described in the draft is very >> problematic. One of the guiding principles of accessibility is that >> services need to be available as widely as possible given PSAP >> capabilities. Attempting to route VRS emergency calls directly will >> actually dramatically reduce the ability of disabled users to reach >> emergency services since video could not be accepted until the PSAP is >> equipped to handle it, even if the interpretation service were able to do >> so, and a call routed via the interpreting service could succeed with >> full functionality. >> >> These are exactly the kinds of issues that would be debated and addressed >> within a WG with appropriate RAI focus, but which are likely to be >> neglected in a WG whose Charter covers both emergency service >> accessibility issues and email language selection. >> >> At a minimum, I would like to see another work item relating to use of >> the proposed language specification, including call flows, within a group >> with emergency services or SIP expertise (such as ECRIT). >> >> >> >> >> >>> On Jul 6, 2015, at 7:13 PM, Rosen, Brian >>> wrote: >>> >>> While I think the “direct model†is actually very problematic, I think >>> that draft is quite appropriate for the basic purpose of making sure a >>> trained call taker gets the call. And, of course, it’s also very useful >>> for generic routing of calls for which a VRS as a “transcoder†would be >>> a >>> much better way to make a generic video call look differently from a VRS >>> video call, and invoke proper treatment. >>> >>> It’s also a better way to announce a VRS call to the call taker. Today, >>> we don’t know it from any other 3rd party initiated video call. >>> >>> As Randy says, we’ve discussed these issues with the NENA Accessibility >>> groups as well as the FCC accessibility committee folks. We’ve also >>> been >>> discussing the issues with PSAPs who have some multi-lingual call >>> takers, >>> and would very much appreciate being able to route to the right queue. >>> And, of course, improving how PSAPs handle “Language Line†services is >>> one >>> of the basic goals of this work. The direct model would make VRS look >>> exactly like Language Line. >>> >>> Brian >>> >>> >>> >>> >>> >>>> On 7/6/15, 8:35 PM, "Randall Gellens" wrote: >>>> >>>> Hi Bernard, >>>> >>>> I'd like to discuss your concerns a bit. I've added Brian Rosen to >>>> the email as he is chair of the NG (i3) architecture group in NENA. >>>> >>>> I'm trying to understand why you believe that the call flow in 4.5 >>>> would result in rejection of the video stream, rather than the PSAP >>>> engaging an interpretation service. As you say, we are trying to >>>> move from today's model in which the caller first calls the relay >>>> service, and then the relay service bridges in the PSAP, to a direct >>>> model where the caller calls 911 directly, and the PSAP bridges in >>>> the relay service. Obviously, there are funding issues that would >>>> need to be handled in order for PSAPs to be able to invoke relay >>>> services, but both the next-gen and accessibility groups in NENA want >>>> a direct model (which offers many advantages, including priority >>>> treatment and location delivery). The NENA Policy-Based Routing >>>> (PBR) functionality within an ESInet has the ability to use the SDP >>>> when making routing decisions (in case PSAPs have cooperation >>>> agreements where some PSAPs handle some types of calls or some >>>> languages or media). >>>> >>>> The draft and the issues have been discussed with the co-chairs of >>>> the NENA accessibility WG, and they are strongly in favor of a direct >>>> model for next-gen. >>>> >>>> In the U.S., emergency call routing is first by location, and then by >>>> local rules (if any). For example, if a call requires text, there >>>> might be some PSAPs in a cooperating group that take text calls on >>>> behalf of others. Likewise if the call requests audio or textual >>>> Spanish. In Europe, various models are under discussion, including >>>> some in which a call might be routed to a PSAP in a country where the >>>> caller's language is native. The draft allows this flexibility: the >>>> call can be routed to a specific PSAP (and even call taker) or the >>>> PSAP can bridge in translation or relay services at the start of the >>>> call. >>>> >>>> At 5:15 PM -0700 7/1/15, Bernard Aboba wrote: >>>> >>>>> I believe that this Charter is poorly suited to developing >>>>> solutions to the problem faced by disabled users of realtime >>>>> emergency services. >>>>> >>>>> In the case of access to emergency services by the disabled, the >>>>> goal is not "selection of the best-fit language", but rather, >>>>> routing of the call and media so as to pull together the services >>>>> best fitting the emergency situation and the disabilities of the >>>>> caller, as well as the capabilities of the device and >>>>> intermediaries which may sit between the caller and the PSAP. Not >>>>> only are media and language intrinsically linked, but also, the >>>>> ways in which calls are routed is influenced and in some cases >>>>> prescribed by regulation and national standards. >>>>> >>>>> Simply put, draft-gellens-slim-negotiating-human-language lacks >>>>> appropriate consideration of the problem context. Specifying it as >>>>> the starting point is therefore inappropriate. As an example, today >>>>> the call flow described in Section 4.5 would most likely result in >>>>> rejection of the video portion of the call by the PSAP, leaving the >>>>> dispatcher with no means of communicating with the hearing-impaired >>>>> caller, thus leaving the caller worse off than they are today >>>>> attempting to make an emergency call within the (cumbersome and >>>>> error/delay-prone) Video Relay Service. A fuller consideration of >>>>> the problem context would involve consideration of current >>>>> operation of relay services and proposals for their evolution. >>>>> Attempting to develop this problem context within a WG that is >>>>> also attempting to deal with language-selection in email would be >>>>> frustrating at best. >>>>> >>>>> A sensible Charter would also probably include liaisons with >>>>> disability rights organizations, groups specifying the operation of >>>>> relay services, and groups considering next steps for access to >>>>> emergency services. >>>>> >>>>>> From: iesg@ietf.org >>>>>> To: new-work@ietf.org >>>>>> Date: Fri, 26 Jun 2015 08:36:05 -0700 >>>>>> Subject: [new-work] WG Review: Selection of Language for Internet >>>>>> Media (slim) >>>>>> >>>>>> A new IETF working group has been proposed in the Applications and >>>>>> Real-Time Area. The IESG has not made any determination yet. The >>>>>> following draft charter was submitted, and is provided for >>>>>> informational >>>>>> purposes only. Please send your comments to the IESG mailing list >>>>>> (iesg >>>>>> at ietf.org) by 2015-07-06. >>>>>> >>>>>> Selection of Language for Internet Media (slim) >>>>>> ------------------------------------------------ >>>>>> Current Status: Proposed WG >>>>>> >>>>>> Assigned Area Director: >>>>>> Barry Leiba >>>>>> >>>>>> Mailing list >>>>>> Address: slim@ietf.org >>>>>> To Subscribe: https://www.ietf.org/mailman/listinfo/slim >>>>>> Archive: https://mailarchive.ietf.org/arch/browse/slim/ >>>>>> >>>>>> Charter: >>>>>> >>>>>> Description of Working Group: >>>>>> >>>>>> A mutually comprehensible language is helpful for human >>>>>> communication. >>>>>> This is true across a range of circumstances and environments. In >>>>>> general, the problem is most acute in situations where there is not a >>>>>> clear choice for a single language, such as environments lacking >>>>>> contextual or out-of-band information regarding the identity of the >>>>>> parties and the language to be used. >>>>>> >>>>>> The group will address two specific cases that most urgently need a >>>>>> technical solution: One problem space is non-real-time communication, >>>>>> specifically email for one-to-many or where the set of recipients is >>>>>> dynamic or different recipients require different languages; the >>>>>> other is >>>>>> real-time communication, specifically emergency calling, preferably >>>>>> also >>>>>> useful for other cases where the parties may not know each other >>>>>> personally or where one party wishes to accommodate people with >>>>>> varying >>>>>> language and media needs. >>>>>> >>>>>> In the real-time communication case, language and media are >>>>>> intrinsically >>>>>> linked, for example, signed languages require a video media. >>>>>> >>>>>> While the two use cases are in different contexts (real time and >>>>>> non-real-time), the fundamental goal is the same: to enable selection >>>>>> of >>>>>> the best-fit language(s) for a specific situation. Some of the >>>>>> details >>>>>> will also be in common across the cases, e.g., the language tags. >>>>>> Having >>>>>> a single WG address both cases makes it clear that these are two >>>>>> aspects >>>>>> of the same basic problem. A single WG also makes it easier to >>>>>> maximize >>>>>> similarities and avoid unnecessary fragmentation of the solutions, >>>>>> and >>>>>> facilitates broader review. >>>>>> >>>>>> The group will produce two documents, one for email, and one for >>>>>> real-time communications. >>>>>> >>>>>> In the email case, the group will determine a MIME based solution >>>>>> that >>>>>> enables a single email message to contain multiple language versions >>>>>> of >>>>>> the content, with provisions to help clients select a best fit >>>>>> version. >>>>>> >>>>>> In the real-time communication case, the group will produce a >>>>>> specification based on draft-gellens-slim-negotiating-human-language, >>>>>> enabling negotiation of a human language per media stream. The >>>>>> specification must be suitable for use in emergency communications as >>>>>> specified in RFC 6443 and RFC 6881 (which use SIP and SDP to >>>>>> negotiate >>>>>> media); it is desirable to also be suitable for use in non-emergency >>>>>> real-time communications that share the same call set-up and media >>>>>> negotiation protocols. The mechanism will permit the caller's media >>>>>> and >>>>>> language needs and preferences to be matched against what the called >>>>>> party is able to provide. The mechanism will permit resources (e.g., >>>>>> translation, relay, media) to be allocated or engaged as early as >>>>>> possible in the call set-up or for the call to be routed or handled >>>>>> specially (e.g., routed to a resource able to provide a needed >>>>>> language >>>>>> and/or media). Alternatives such as doing the negotiation in SIP have >>>>>> been thoroughly explored in the past and are out of scope (although >>>>>> the >>>>>> scope might be extended after the SDP mechanism has been advanced). >>>>>> >>>>>> By adding language to the existing media negotiation mechanism as >>>>>> used in >>>>>> RFC 6443 and RFC 6881, the group can meet the basic use cases with >>>>>> minimal added complexity and be able to enhance later for additional >>>>>> use >>>>>> cases as needed. >>>>>> >>>>>> Milestones: >>>>>> Oct 2015 - Submit "Multiple Language Content Type" to the IESG (based >>>>>> on draft-tomkinson-slim-multilangcontent) >>>>>> Feb 2016 - Submit "Negotiating Human Language in Real-Time >>>>>> Communications" to the IESG (based on >>>>>> draft-gellens-slim-negotiating-human-language) >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> new-work mailing list >>>>>> new-work@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/new-work >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself only >>>> -------------- Randomly selected tag: --------------- >>>> Just because you do not take an interest in politics doesn't mean >>>> politics won't take and interest in you. --Pericles (495-425 BC) > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Tue Jul 7 08:31:37 2015 Return-Path: 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 EB0BD1A88EC; Tue, 7 Jul 2015 08:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 JRpaIqFMiep5; Tue, 7 Jul 2015 08:31:31 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2DF1A8863; Tue, 7 Jul 2015 08:31:31 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t67FVSCk029622; Tue, 7 Jul 2015 11:31:29 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1vg17us4pr-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 07 Jul 2015 11:31:29 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.249]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 7 Jul 2015 11:31:22 -0400 From: "Rosen, Brian" To: =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= Thread-Topic: [Ecrit] [new-work] WG Review: Selection of Language for Internet Media (slim) Thread-Index: AQHQuMn6N/Xj9KjTdEOczlQHvDygLQ== Date: Tue, 7 Jul 2015 15:31:22 +0000 Message-ID: <97EB2758-1BD6-41EF-95C1-5A557AB9718E@neustar.biz> References: <20150626153605.18943.13946.idtracker@ietfa.amsl.com> <559BE96D.2030502@omnitor.se> In-Reply-To: <559BE96D.2030502@omnitor.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.32] Content-Type: text/plain; charset="utf-8" Content-ID: <9A57A67A34194B418A47331B5FB888EA@neustar.biz> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-07_05:2015-07-07,2015-07-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "slim@ietf.org" , Randall Gellens , "ecrit@ietf.org" Subject: Re: [Ecrit] [new-work] WG Review: Selection of Language for Internet Media (slim) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 15:31:36 -0000 DQpTZWUgaW5saW5lDQo+IE9uIEp1bCA3LCAyMDE1LCBhdCAxMDo1OSBBTSwgR3VubmFyIEhlbGxz dHLDtm0gPGd1bm5hci5oZWxsc3Ryb21Ab21uaXRvci5zZT4gd3JvdGU6DQo+IA0KPiBJIGRlbGV0 ZWQgaWV0ZiBhbmQgaWVzZyBmcm9tIHRoZSBhZGRyZXNzZXMgYW5kIGFkZGVkIHNsaW0uIEJ1dCB5 b3UgYXJlIHJpZ2h0IHRoYXQgdGhpcyBpcyBhIGdlbmVyYWwgc2lwIHRvcGljIGFzIHdlbGwuDQo+ IEp1c3QgdGVsbCB3aGVyZSB3ZSBzaGFsbCBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbi4NCkkgdGhp bmsgdGhpcyBkaXNjdXNzaW9uIHNob3VsZCBiZSBoZWxkIG9uIHRoZSBzbGltLCBidXQgSSBsZWZ0 IGVjcml0IGluLg0KDQo+IA0KPiBBYm91dCB3b3JrIGl0ZW1zOiBJIHRoaW5rIHNsaW0gY2FuIGNv bnRpbnVlIHRvIGNyZWF0ZSBpdHMgcGxhbm5lZCBtZWRpYSBhbmQgbW9kYWxpdHkgaW5kaWNhdGlv bnMuDQo+IEJ1dCB3b3JrIGlzIG5lZWRlZCBvbiB0aGUgcm91dGluZyBtZWNoYW5pc21zIHVzaW5n IFNMSU0gYW5kIG90aGVyIGluZGljYXRpb25zIHRvIGRlY2lkZSBvbiBjb25uZWN0aW9uIG9mIHVz ZXJzIGFuZCBvcHRpb25hbGx5IGFzc2lzdGluZyBzZXJ2aWNlcyAoc3VjaCBhcyByZWxheSkuDQpJ RVRGIGhhcyBubyB3b3JrIGdyb3VwIHRoYXQgaGFuZGxlcyByZWxheSBvciBhbnkgb3RoZXIgYXNz aXN0ZWQgc2VydmljZS4gIFdl4oCZbGwgaGF2ZSB0byBkbyBpdCBpbiBkaXNwYXRjaCBJIHRoaW5r LCBvciBzaXBjb3JlLg0KPiANCj4gSXQgaXMgYmV0dGVyIGlmIHRoZSBtZWNoYW5pc21zIGFyZSBn ZW5lcmFsLCBhbmQgbm90IGVtZXJnZW5jeSBzZXJ2aWNlIHNwZWNpZmljLiBPbmUgcmVhc29uIGlz IHRoYXQgdXNlcnMgd2lsbCB0aGVuIGhhdmUgbXVjaCBoaWdoZXIgdGVuZGVuY3kgdG8ga2VlcCB0 aGVpciBwcmVmZXJlbmNlIHNldHRpbmdzIGluIG9yZGVyLiBBbm90aGVyIHJlYXNvbiBpcyB0aGF0 IGxhcmdlIHBhcnRzIG9mIHRoZSBtZWNoYW5pc21zIHdpbGwgYmUgdXNlZCBhbmQgdmVyaWZpZWQg dG8gd29yay4gVGhlIGVtZXJnZW5jeSBzZXJ2aWNlIHNwZWNpZmljIG1lY2hhbmlzbXMgaGF2ZSB0 aGUgcmlzayBvZiBub3QgYmVpbmcgdGhvcm91Z2hseSB0ZXN0ZWQgZm9yIGV2ZXJ5IGtpbmQgb2Yg dGVybWluYWwvc2VydmljZSBwcm92aWRlci9tb2RhbGl0eSBjb21iaW5hdGlvbi4NCkkgYWdyZWUg Y29tcGxldGVseS4gIFdlIHJlYWxseSB3YW50IHRoZSBzbGltIG1lY2hhbmlzbSB0byBiZSBUSEUg d2F5IHdlIGhhbmRsZSBhIHJlcXVlc3QgZm9yIHJlbGF5LCBqdXN0IGxpa2Ugd2Ugd2FudCBpdCB0 byBiZSB0aGUgd2F5IHdlIHJlcXVlc3QgbGFuZ3VhZ2Ugcm91dGluZyBvciB0cmFuc2xhdGlvbiBm b3IgYW55IG90aGVyIGxhbmd1YWdlDQo+IA0KPiBJTiBFVFNJIFNURiA0ODkgd2UgYXJlIHJpZ2h0 IG5vdyBpbnRlbnNpdmVseSBkaXNjdXNzaW5nIHRoZSB0b3BpY3MgaW4gdGhpcyB0aHJlYWQsIGFu ZCBoYXZlIGEgbmVlZCB0byBjb21lIHRvIGNvbmNsdXNpb25zIG9uIHJlYWxpc3RpYyBtZWNoYW5p c21zIHRoYXQgb3B0aW1pc2UgdXNlciBiZW5lZml0cyBpbiB0aGUgZW1lcmdlbmN5IGNhbGwgc2Nl bmFyaW9zLg0KV2UgY2FuIHdvcmsgb24gdGhlIGVtZXJnZW5jeSBjYWxsIHNjZW5hcmlvIGluIHNs aW0gd2l0aCBlY3JpdCBwYXJ0aWNpcGF0aW9uLiAgSSBkb27igJl0IHRoaW5rIHRoZXJlIGlzIGVu b3VnaCB0ZXh0IHRvIGp1c3RpZnkgYSBzZXBhcmF0ZSBkb2N1bWVudC4NCj4gDQo+IE9uZSByaXNr IHdlIGhhdmUgc2VlbiBpcyB3aGF0IEJyaWFuIGFsc28gZGVzY3JpYmVzLiBBIGNhbGwgd2l0aCBl LmcuIHRvdGFsIGNvbnZlcnNhdGlvbiBiZWluZyByb3V0ZWQgdG8gYW4gRVNJbmV0IGVudHJ5IG9m IGEgY291bnRyeSBhdCB0aGUgbW9tZW50IG9ubHkgc3VwcG9ydGluZyBzcGVlY2ggaW4gdGhlIFBT QVBzLiBJZiBpdCBpcyBhIGNhbGwgcmVxdWlyaW5nIHNpZ24gbGFuZ3VhZ2UgdHJhbnNsYXRpb24s IGl0IGlzIHRydWUgdGhhdCB0aGUgRVNJbmV0IG9yIFBTQVAgYnJpZGdlIGNvdWxkIHN1cHBvcnQg dmlkZW8gYW5kIHJlYWwtdGltZSB0ZXh0IGV2ZW4gaWYgbm8gUFNBUCBpbiB0aGF0IG5ldHdvcmsg ZG9lcyBzby4gVGhlbiB3ZSBjYW4gZ2V0IGEgcHJvcGVyIHZpZGVvIHJlbGF5IGludm9rZWQgYW5k IGFjY2VwdCB0byBoYXZlIHRoZSBjb21tdW5pY2F0aW9uIHdpdGggdGhlIFBTQVAgaW4gc3BlZWNo IHdpdGggdGhlIGludGVycHJldGVyLg0KUmlnaHQNCj4gDQo+IEJ1dCBob3cgY2FuIHdlIGhhbmRs ZSB0aGUgc2l0dWF0aW9uIHRoYXQgdGhlcmUgaXMgYSBnYXAgaW4gTkcxMTIgaW1wbGVtZW50YXRp b24uIFRoZSB1c2VyIGlzIGluIGEgY291bnRyeSBzdGlsbCBvbiBQU1ROIGZvciAxMTIuIFRoZSBz ZWFyY2ggZm9yIGFuIEVTSW5ldCBlbnRyeSBmb3IgdGhhdCBjb3VudHJ5IHdpbGwgZmFpbCBhbmQg dGhlIFNJUCBzZXJ2aWNlIHByb3ZpZGVyIG5lZWQgdG8gY29udmVydCB0byBQU1ROIGVtZXJnZW5j eSBjYWxsaW5nLiBUaGVuIGl0IGNhbiBub3QgYmUgZXhwZWN0ZWQgdGhhdCB0aGUgMTEyIG5ldHdv cmsgY2FuIGJyaWRnZSB0aGUgbXVsdGltZWRpYSBjYWxsLiAgSXQgc2VlbXMgdG8gbWUgdGhhdCBm b3IgdGhhdCBjYXNlLCB0aGUgdXNlciB0ZXJtaW5hbCBvciBzaXAgc2VydmljZSBwcm92aWRlciBu ZWVkcyB0byBoYXZlIHRoZSBicmlkZ2UgZm9yIHRoYXQgY2FzZS4NCldl4oCZdmUgZGlzY3Vzc2Vk IHRoZSBnZW5lcmFsIHByb2JsZW0gb2YgaG93IGRvZXMgYW4gb3JpZ2luYXRpb24gY2FycmllciBr bm93IHRoYXQgYSBjYWxsIGZyb20gYSBwYXJ0aWN1bGFyIGxvY2F0aW9uIGlzIGRlc3RpbmVkIGZv ciBhIGNvbnZlcnRlZCAoaS5lLiBORzktMS0xL1JGQzY4ODEpIFBTQVAsIG9yIG5vdC4gIFdl4oCZ cmUgaGVhZGluZyB0b3dhcmRzIGhhdmluZyBzb21lIExvU1QgcmVzcG9uc2UgdGhhdCBpbmRpY2F0 ZWQgdGhhdCBmYWN0LiAgIFRoYXQgY291bGQgYmUgdXNlZCBieSB0aGUgc2lwIHNlcnZpY2UgcHJv dmlkZXIgdG8gZGVjaWRlIHdoYXQgdG8gZG8uICANCj4gDQo+IFRoYXQgbWVhbnMgdGhhdCB3ZSBl bmQgdXAgd2l0aCByZWNvbW1lbmRhdGlvbnMgdG8gaGF2ZSBicmlkZ2VzIGluIHZhcmlvdXMgcGxh Y2VzIHRvIGJlIGFibGUgdG8gaGFuZGxlIHRoZSBkaWZmZXJlbnQgY2FsbCBzY2VuYXJpb3Mgb3B0 aW1hbGx5LiBEbyB5b3UgYWdyZWU/DQpZZXMsIGJ1dCBJIHRoaW5rIHRoZXJlIGFyZSBleGFjdGx5 IHR3byBwbGFjZXMgLSB0aGUgcmVsYXkgcHJvdmlkZXIgYW5kIHRoZSBQU0FQLg0KPiANCj4gSSBq dXN0IHNlbnQgdG8gU0xJTSBhbHNvIHRoZSB2aWV3IHRoYXQgU0lQIG1lZGlhIGFuZCBsYW5ndWFn ZSB0YWdzIGFzIHRoZXkgYXJlIGRlZmluZWQgdG9kYXkgY2FuIGJlIHVzZWQgdG8gZGV0ZWN0IG5l ZWQgZm9yIHNpZ24gbGFuZ3VhZ2Ugc3VwcG9ydCAoIGFzIGluZGljYXRlZCBpbiBSRkMgNjQ0Myks IHdoaWxlIHRoZSBhc3ltbWV0cmljIG5lZWRzIG9mIGRlYWYtYmxpbmQgY29tbXVuaWNhdGlvbiBv ciBoYXJkLW9mIGhlYXJpbmcgY29tbXVuaWNhdGlvbiB3aWxsIHJlcXVpcmUgc2xpbS1zdHlsZSBp bmRpY2F0aW9ucyBhbmQgeWV0IHJlbGF5IHNlcnZpY2UgdXNlcnMgb2Ygc3BlZWNoLXRvLXNwZWVj aCBhbmQgY2FwdGlvbmVkIHRlbGVwaG9ueSBzZXJ2aWNlcyBjYW5ub3QgZGVzY3JpYmUgdGhlaXIg bmVlZHMgd2l0aCB0aGUgY3VycmVudCBwcm9wb3NlZCBjb2Rpbmcgb2Ygc2xpbSwgYW5kIHdvdWxs ZCBsaWtlbHkgYmUgYmV0dGVyIG9mZiB0byBoYXZlIGEgcG9zc2liaWxpdHkgdG8ganVzdCByZXF1 ZXN0IGFuIGFzc2lzdGluZyBzZXJ2aWNlIGJ5IGEgVVJJIGFuZCBhIHNpcCBvcGVyYXRpb24uDQpJ IHdvdWxkIHRoaW5rIHdlIGFkZCBsYW5ndWFnZSB0YWdzIGZvciB0aGVzZSBjYXNlcy4gIA0KDQo+ IA0KPiBUaHVzIHNsaW0gaXMgb25seSBwYXJ0IG9mIHRoZSBzb2x1dGlvbi4gSXQgd291bGQgYmUg Z29vZCB0byBoYXZlIHNvbWV3aGVyZSB0byBkaXNjdXNzIHRoZSB3aG9sZSBwaWN0dXJlIGFuZCBz ZXQgc2xpbSBhbmQgdGhlIG90aGVyIG1lY2hhbmlzbXMgaW4gdGhlaXIgY29udGV4dC4NCj4gV2hl cmU/DQpEaXNwYXRjaCB0byBzdGFydC4gIFRoZW4gd2UgY2FuIGRlY2lkZSB3aGVyZSB0byBkbyBh bnkgd29yayB3ZSB0aGluayB3ZSBuZWVkLg0KDQo+IA0KPiBHdW5uYXINCj4gDQo+IFJvc2VuLCBC cmlhbiBza3JldiBkZW4gMjAxNS0wNy0wNyAxNDo1MToNCj4+IEJ1dCB0aGUgZHJhZnQgZG9lc27i gJl0IHN1Z2dlc3QgdGhhdCB0aGUgZGlyZWN0IG1vZGVsIHNob3VsZCByZXBsYWNlIHRoZQ0KPj4g Y3VycmVudCBlbWVyZ2VuY3kgY2FsbCByb3V0aW5nLCBpdCBtZXJlbHkgYWxsb3dzIG5ldyBjYXBh YmlsaXR5LiAgSWYgdGhlcmUNCj4+IGlzIGFueSBsYW5ndWFnZSB5b3UgZmluZCB0aGF0IG1ha2Vz IGl0IHNlZW0gbGlrZSBkaXJlY3Qgcm91dGluZyBzaG91bGQgYmUNCj4+IHByZWZlcnJlZCBvdmVy IHRoZSBjdXJyZW50IGxvY2F0aW9uIGJhc2VkIHJvdXRpbmcsIHdlIGNhbiBhZGRyZXNzIHRoYXQu DQo+PiANCj4+IE9uIHlvdXIgc3BlY2lmaWMgcG9pbnQgYWJvdXQgbm90IGJlaW5nIGFibGUgdG8g ZGVhbCB3aXRoIG5vbi12aWRlbw0KPj4gZXF1aXBwZWQgUFNBUHMsIHdlIGhhdmUgcGxlbnR5IG9m IG1lY2hhbmlzbXMgYXZhaWxhYmxlIHRvIHJlYWRpbHkNCj4+IGFjY29tbW9kYXRlIHRoYXQgc2l0 dWF0aW9uLiAgRGV2aWNlcyBhcmUgcmVxdWlyZWQgdG8gZm9sbG93IGV4aXN0aW5nDQo+PiBwcmFj dGljZSBvZiBmb3J3YXJkaW5nIGNhbGxzIHRvIHRoZWlyIG5vcm1hbCBvdXRib3VuZCBwcm94eSwg YW5kIHRoaXMNCj4+IGRyYWZ0IGRvZXNu4oCZdCBjaGFuZ2UgdGhhdCBhdCBhbGwuICBXaGF0IGhh cHBlbnMgYWZ0ZXIgdGhhdCBpcyBjb25maW5lZCB0bw0KPj4gd2hhdCB0aGUgc2VydmljZXMgdGhh dCBwcm92aWRlIHJvdXRpbmcgZm9yIFZSUywgYW5kIHdlIGNhbiBoYW5kbGUgbG9jYXRpb24NCj4+ IHNlbnNpdGl2ZSBoYW5kbGluZyBvZiBzdWNoIGNhbGxzLiAgQWxsIDktMS0xIGNhbGxzIGFyZSDi gJxkaXJlY3TigJ0gcm91dGVkLCBpbg0KPj4gdGhhdCB0aGV5IHJvdXRlIHRvIHRoZSBvdXRib3Vu ZCBwcm94eSwgd2hpY2ggcm91dGVzIGJhc2VkIG9uIHRoZSBMb1NUDQo+PiBxdWVyeSByZXN1bHQs IGFuZCB0aGF0IGlzIG5vdCBtZWRpYSBzZW5zaXRpdmUuICBUaGF0IGRlbGl2ZXJzIHRoZSBjYWxs IHRvDQo+PiB0aGUgcmlnaHQgaW5ib3VuZCBwcm94eSBzZXJ2ZXIsIHdoaWNoIHRoZW4gaXMgYWJs ZSB0byByb3V0ZSBiYXNlZCBvbg0KPj4gbWVkaWEsIGlmIGRlc2lyZWQuDQo+PiANCj4+IFRoZSB3 YXkgd2UgaGFuZGxlIFZSUywgYW5kIHN0aWxsIGdldCBjYWxscyByb3V0ZWQgYnkgdGhlIGxvY2F0 aW9uIG9mIHRoZQ0KPj4gY2FsbGVyIGlzIHRvIGhhdmUgdGhlIFZSUyBzZXJ2aWNlIHJvdXRlIHRo ZSBjYWxsIGxpa2UgYW55IG90aGVyIDktMS0xIGNhbGwNCj4+IHdvdWxkIGJlIHJvdXRlZCwgYnV0 IHRoZXkgYWRkIGEgaGVhZGVyIHRoYXQgaW5mb3JtcyB0aGUgUFNBUCB0aGF0IGEgQ0EgaXMNCj4+ IGF2YWlsYWJsZS4gIFRoZSBQU0FQIHRoZW4gY3JlYXRlcyBhIDMgd2F5IHZpZGVvL2F1ZGlvIGNh bGwgYW1vbmcgdGhlIFBTQVAsDQo+PiB0aGUgY2FsbGVyIGFuZCB0aGUgQ0EuICBJZiB0aGUgUFNB UCB3aXNoZXMgdG8gdXNlIGl0cyBvd24gQ0EsIGl0IGNhbiBkbw0KPj4gc28sIGJ1dCBpdCBuZWVk cyB0byBrbm93IHRoaXMgaXMgYSBWUlMgY2FsbC4gIFRoZSBQU0FQIGRvZXNu4oCZdCBuZWVkIHRv DQo+PiBoYW5kbGUgdmlkZW8sIHNpbmNlIGlmIGl04oCZcyBub3Qgc2VuZGluZy9yZWNlaXZpbmcg dmlkZW8sIGl04oCZcyBhIDIgd2F5DQo+PiB2aWRlbywgMyB3YXkgYXVkaW8gY2FsbCwgYW5kIGV2 ZW4gaXRzIGJyaWRnZSBkb2VzbuKAmXQgcmVhbGx5IG5lZWQgdG8gYmUgaW4NCj4+IHRoZSB2aWRl byBwYXRoLg0KPj4gDQo+PiBXZSBjZXJ0YWlubHkgY2FuIGhhdmUgZWNyaXQgcmV2aWV3IGRyYWZ0 cyBjb21pbmcgb3V0IG9mIHRoaXMgd29yay4gIE5FTkENCj4+IGFuZCBFRU5BIHdpbGwgYWxzbyBy ZXZpZXcuDQo+PiANCj4+IEkgZG9u4oCZdCBiZWxpZXZlIHRoZXJlIGlzIGEgbmVlZCB0byBoYXZl IGFuIGVudGlyZWx5IHNlcGFyYXRlIGRvY3VtZW50IHRvDQo+PiBoYW5kbGUgdGhlIGVtZXJnZW5j eSBjYWxsIGZsb3dzLiAgV2UganVzdCBuZWVkIGFwcHJvcHJpYXRlIHJldmlldywgd2hpY2gNCj4+ IEnigJltIHN1cmUgd2UgY2FuIGFycmFuZ2UuDQo+PiANCj4+IEJyaWFuDQo+PiANCj4+IE9uIDcv Ni8xNSwgMTE6MzAgUE0sICJCZXJuYXJkIEFib2JhIiA8YmVybmFyZF9hYm9iYUBob3RtYWlsLmNv bT4gd3JvdGU6DQo+PiANCj4+PiBJIGFncmVlIHRoYXQgdGhlICJkaXJlY3QiIG1vZGVsIGRlc2Ny aWJlZCBpbiB0aGUgZHJhZnQgaXMgdmVyeQ0KPj4+IHByb2JsZW1hdGljLiAgT25lIG9mIHRoZSBn dWlkaW5nIHByaW5jaXBsZXMgb2YgYWNjZXNzaWJpbGl0eSBpcyB0aGF0DQo+Pj4gc2VydmljZXMg bmVlZCB0byBiZSBhdmFpbGFibGUgYXMgd2lkZWx5IGFzIHBvc3NpYmxlIGdpdmVuIFBTQVANCj4+ PiBjYXBhYmlsaXRpZXMuIEF0dGVtcHRpbmcgdG8gcm91dGUgVlJTIGVtZXJnZW5jeSBjYWxscyBk aXJlY3RseSB3aWxsDQo+Pj4gYWN0dWFsbHkgZHJhbWF0aWNhbGx5IHJlZHVjZSB0aGUgYWJpbGl0 eSBvZiBkaXNhYmxlZCB1c2VycyB0byByZWFjaA0KPj4+IGVtZXJnZW5jeSBzZXJ2aWNlcyBzaW5j ZSB2aWRlbyBjb3VsZCBub3QgYmUgYWNjZXB0ZWQgdW50aWwgdGhlIFBTQVAgaXMNCj4+PiBlcXVp cHBlZCB0byBoYW5kbGUgaXQsIGV2ZW4gaWYgdGhlIGludGVycHJldGF0aW9uIHNlcnZpY2Ugd2Vy ZSBhYmxlIHRvIGRvDQo+Pj4gc28sIGFuZCBhIGNhbGwgcm91dGVkIHZpYSB0aGUgaW50ZXJwcmV0 aW5nIHNlcnZpY2UgY291bGQgc3VjY2VlZCB3aXRoDQo+Pj4gZnVsbCBmdW5jdGlvbmFsaXR5Lg0K Pj4+IA0KPj4+IFRoZXNlIGFyZSBleGFjdGx5IHRoZSBraW5kcyBvZiBpc3N1ZXMgdGhhdCB3b3Vs ZCBiZSBkZWJhdGVkIGFuZCBhZGRyZXNzZWQNCj4+PiB3aXRoaW4gYSBXRyB3aXRoIGFwcHJvcHJp YXRlIFJBSSBmb2N1cywgYnV0IHdoaWNoIGFyZSBsaWtlbHkgdG8gYmUNCj4+PiBuZWdsZWN0ZWQg aW4gYSBXRyB3aG9zZSBDaGFydGVyIGNvdmVycyBib3RoIGVtZXJnZW5jeSBzZXJ2aWNlDQo+Pj4g YWNjZXNzaWJpbGl0eSBpc3N1ZXMgYW5kIGVtYWlsIGxhbmd1YWdlIHNlbGVjdGlvbi4NCj4+PiAN Cj4+PiBBdCBhIG1pbmltdW0sIEkgd291bGQgbGlrZSB0byBzZWUgYW5vdGhlciB3b3JrIGl0ZW0g cmVsYXRpbmcgdG8gdXNlIG9mDQo+Pj4gdGhlIHByb3Bvc2VkIGxhbmd1YWdlIHNwZWNpZmljYXRp b24sIGluY2x1ZGluZyBjYWxsIGZsb3dzLCB3aXRoaW4gYSBncm91cA0KPj4+IHdpdGggZW1lcmdl bmN5IHNlcnZpY2VzIG9yIFNJUCBleHBlcnRpc2UgKHN1Y2ggYXMgRUNSSVQpLg0KPj4+IA0KPj4+ IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+PiBPbiBKdWwgNiwgMjAxNSwgYXQgNzoxMyBQTSwgUm9z ZW4sIEJyaWFuIDxCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpej4NCj4+Pj4gd3JvdGU6DQo+Pj4+IA0K Pj4+PiBXaGlsZSBJIHRoaW5rIHRoZSDigJxkaXJlY3QgbW9kZWzigJ0gaXMgYWN0dWFsbHkgdmVy eSBwcm9ibGVtYXRpYywgSSB0aGluaw0KPj4+PiB0aGF0IGRyYWZ0IGlzIHF1aXRlIGFwcHJvcHJp YXRlIGZvciB0aGUgYmFzaWMgcHVycG9zZSBvZiBtYWtpbmcgc3VyZSBhDQo+Pj4+IHRyYWluZWQg Y2FsbCB0YWtlciBnZXRzIHRoZSBjYWxsLiAgQW5kLCBvZiBjb3Vyc2UsIGl04oCZcyBhbHNvIHZl cnkgdXNlZnVsDQo+Pj4+IGZvciBnZW5lcmljIHJvdXRpbmcgb2YgY2FsbHMgZm9yIHdoaWNoIGEg VlJTIGFzIGEg4oCcdHJhbnNjb2RlcuKAnSB3b3VsZCBiZQ0KPj4+PiBhDQo+Pj4+IG11Y2ggYmV0 dGVyIHdheSB0byBtYWtlIGEgZ2VuZXJpYyB2aWRlbyBjYWxsIGxvb2sgZGlmZmVyZW50bHkgZnJv bSBhIFZSUw0KPj4+PiB2aWRlbyBjYWxsLCBhbmQgaW52b2tlIHByb3BlciB0cmVhdG1lbnQuDQo+ Pj4+IA0KPj4+PiBJdOKAmXMgYWxzbyBhIGJldHRlciB3YXkgdG8gYW5ub3VuY2UgYSBWUlMgY2Fs bCB0byB0aGUgY2FsbCB0YWtlci4gIFRvZGF5LA0KPj4+PiB3ZSBkb27igJl0IGtub3cgaXQgZnJv bSBhbnkgb3RoZXIgM3JkIHBhcnR5IGluaXRpYXRlZCB2aWRlbyBjYWxsLg0KPj4+PiANCj4+Pj4g QXMgUmFuZHkgc2F5cywgd2XigJl2ZSBkaXNjdXNzZWQgdGhlc2UgaXNzdWVzIHdpdGggdGhlIE5F TkEgQWNjZXNzaWJpbGl0eQ0KPj4+PiBncm91cHMgYXMgd2VsbCBhcyB0aGUgRkNDIGFjY2Vzc2li aWxpdHkgY29tbWl0dGVlIGZvbGtzLiAgV2XigJl2ZSBhbHNvDQo+Pj4+IGJlZW4NCj4+Pj4gZGlz Y3Vzc2luZyB0aGUgaXNzdWVzIHdpdGggUFNBUHMgd2hvIGhhdmUgc29tZSBtdWx0aS1saW5ndWFs IGNhbGwNCj4+Pj4gdGFrZXJzLA0KPj4+PiBhbmQgd291bGQgdmVyeSBtdWNoIGFwcHJlY2lhdGUg YmVpbmcgYWJsZSB0byByb3V0ZSB0byB0aGUgcmlnaHQgcXVldWUuDQo+Pj4+IEFuZCwgb2YgY291 cnNlLCBpbXByb3ZpbmcgaG93IFBTQVBzIGhhbmRsZSDigJxMYW5ndWFnZSBMaW5l4oCdIHNlcnZp Y2VzIGlzDQo+Pj4+IG9uZQ0KPj4+PiBvZiB0aGUgYmFzaWMgZ29hbHMgb2YgdGhpcyB3b3JrLiAg VGhlIGRpcmVjdCBtb2RlbCB3b3VsZCBtYWtlIFZSUyBsb29rDQo+Pj4+IGV4YWN0bHkgbGlrZSBM YW5ndWFnZSBMaW5lLg0KPj4+PiANCj4+Pj4gQnJpYW4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+ Pj4gDQo+Pj4+IA0KPj4+Pj4gT24gNy82LzE1LCA4OjM1IFBNLCAiUmFuZGFsbCBHZWxsZW5zIiA8 cmFuZHlAcXRpLnF1YWxjb21tLmNvbT4gd3JvdGU6DQo+Pj4+PiANCj4+Pj4+IEhpIEJlcm5hcmQs DQo+Pj4+PiANCj4+Pj4+IEknZCBsaWtlIHRvIGRpc2N1c3MgeW91ciBjb25jZXJucyBhIGJpdC4g IEkndmUgYWRkZWQgQnJpYW4gUm9zZW4gdG8NCj4+Pj4+IHRoZSBlbWFpbCBhcyBoZSBpcyBjaGFp ciBvZiB0aGUgTkcgKGkzKSBhcmNoaXRlY3R1cmUgZ3JvdXAgaW4gTkVOQS4NCj4+Pj4+IA0KPj4+ Pj4gSSdtIHRyeWluZyB0byB1bmRlcnN0YW5kIHdoeSB5b3UgYmVsaWV2ZSB0aGF0IHRoZSBjYWxs IGZsb3cgaW4gNC41DQo+Pj4+PiB3b3VsZCByZXN1bHQgaW4gcmVqZWN0aW9uIG9mIHRoZSB2aWRl byBzdHJlYW0sIHJhdGhlciB0aGFuIHRoZSBQU0FQDQo+Pj4+PiBlbmdhZ2luZyBhbiBpbnRlcnBy ZXRhdGlvbiBzZXJ2aWNlLiAgQXMgeW91IHNheSwgd2UgYXJlIHRyeWluZyB0bw0KPj4+Pj4gbW92 ZSBmcm9tIHRvZGF5J3MgbW9kZWwgaW4gd2hpY2ggdGhlIGNhbGxlciBmaXJzdCBjYWxscyB0aGUg cmVsYXkNCj4+Pj4+IHNlcnZpY2UsIGFuZCB0aGVuIHRoZSByZWxheSBzZXJ2aWNlIGJyaWRnZXMg aW4gdGhlIFBTQVAsIHRvIGEgZGlyZWN0DQo+Pj4+PiBtb2RlbCB3aGVyZSB0aGUgY2FsbGVyIGNh bGxzIDkxMSBkaXJlY3RseSwgYW5kIHRoZSBQU0FQIGJyaWRnZXMgaW4NCj4+Pj4+IHRoZSByZWxh eSBzZXJ2aWNlLiAgT2J2aW91c2x5LCB0aGVyZSBhcmUgZnVuZGluZyBpc3N1ZXMgdGhhdCB3b3Vs ZA0KPj4+Pj4gbmVlZCB0byBiZSBoYW5kbGVkIGluIG9yZGVyIGZvciBQU0FQcyB0byBiZSBhYmxl IHRvIGludm9rZSByZWxheQ0KPj4+Pj4gc2VydmljZXMsIGJ1dCBib3RoIHRoZSBuZXh0LWdlbiBh bmQgYWNjZXNzaWJpbGl0eSBncm91cHMgaW4gTkVOQSB3YW50DQo+Pj4+PiBhIGRpcmVjdCBtb2Rl bCAod2hpY2ggb2ZmZXJzIG1hbnkgYWR2YW50YWdlcywgaW5jbHVkaW5nIHByaW9yaXR5DQo+Pj4+ PiB0cmVhdG1lbnQgYW5kIGxvY2F0aW9uIGRlbGl2ZXJ5KS4gIFRoZSBORU5BIFBvbGljeS1CYXNl ZCBSb3V0aW5nDQo+Pj4+PiAoUEJSKSBmdW5jdGlvbmFsaXR5IHdpdGhpbiBhbiBFU0luZXQgaGFz IHRoZSBhYmlsaXR5IHRvIHVzZSB0aGUgU0RQDQo+Pj4+PiB3aGVuIG1ha2luZyByb3V0aW5nIGRl Y2lzaW9ucyAoaW4gY2FzZSBQU0FQcyBoYXZlIGNvb3BlcmF0aW9uDQo+Pj4+PiBhZ3JlZW1lbnRz IHdoZXJlIHNvbWUgUFNBUHMgaGFuZGxlIHNvbWUgdHlwZXMgb2YgY2FsbHMgb3Igc29tZQ0KPj4+ Pj4gbGFuZ3VhZ2VzIG9yIG1lZGlhKS4NCj4+Pj4+IA0KPj4+Pj4gVGhlIGRyYWZ0IGFuZCB0aGUg aXNzdWVzIGhhdmUgYmVlbiBkaXNjdXNzZWQgd2l0aCB0aGUgY28tY2hhaXJzIG9mDQo+Pj4+PiB0 aGUgTkVOQSBhY2Nlc3NpYmlsaXR5IFdHLCBhbmQgdGhleSBhcmUgc3Ryb25nbHkgaW4gZmF2b3Ig b2YgYSBkaXJlY3QNCj4+Pj4+IG1vZGVsIGZvciBuZXh0LWdlbi4NCj4+Pj4+IA0KPj4+Pj4gSW4g dGhlIFUuUy4sIGVtZXJnZW5jeSBjYWxsIHJvdXRpbmcgaXMgZmlyc3QgYnkgbG9jYXRpb24sIGFu ZCB0aGVuIGJ5DQo+Pj4+PiBsb2NhbCBydWxlcyAoaWYgYW55KS4gIEZvciBleGFtcGxlLCBpZiBh IGNhbGwgcmVxdWlyZXMgdGV4dCwgdGhlcmUNCj4+Pj4+IG1pZ2h0IGJlIHNvbWUgUFNBUHMgaW4g YSBjb29wZXJhdGluZyBncm91cCB0aGF0IHRha2UgdGV4dCBjYWxscyBvbg0KPj4+Pj4gYmVoYWxm IG9mIG90aGVycy4gIExpa2V3aXNlIGlmIHRoZSBjYWxsIHJlcXVlc3RzIGF1ZGlvIG9yIHRleHR1 YWwNCj4+Pj4+IFNwYW5pc2guICBJbiBFdXJvcGUsIHZhcmlvdXMgbW9kZWxzIGFyZSB1bmRlciBk aXNjdXNzaW9uLCBpbmNsdWRpbmcNCj4+Pj4+IHNvbWUgaW4gd2hpY2ggYSBjYWxsIG1pZ2h0IGJl IHJvdXRlZCB0byBhIFBTQVAgaW4gYSBjb3VudHJ5IHdoZXJlIHRoZQ0KPj4+Pj4gY2FsbGVyJ3Mg bGFuZ3VhZ2UgaXMgbmF0aXZlLiAgVGhlIGRyYWZ0IGFsbG93cyB0aGlzIGZsZXhpYmlsaXR5OiB0 aGUNCj4+Pj4+IGNhbGwgY2FuIGJlIHJvdXRlZCB0byBhIHNwZWNpZmljIFBTQVAgKGFuZCBldmVu IGNhbGwgdGFrZXIpIG9yIHRoZQ0KPj4+Pj4gUFNBUCBjYW4gYnJpZGdlIGluIHRyYW5zbGF0aW9u IG9yIHJlbGF5IHNlcnZpY2VzIGF0IHRoZSBzdGFydCBvZiB0aGUNCj4+Pj4+IGNhbGwuDQo+Pj4+ PiANCj4+Pj4+IEF0IDU6MTUgUE0gLTA3MDAgNy8xLzE1LCBCZXJuYXJkIEFib2JhIHdyb3RlOg0K Pj4+Pj4gDQo+Pj4+Pj4gSSBiZWxpZXZlIHRoYXQgdGhpcyBDaGFydGVyIGlzIHBvb3JseSBzdWl0 ZWQgdG8gZGV2ZWxvcGluZw0KPj4+Pj4+IHNvbHV0aW9ucyB0byB0aGUgcHJvYmxlbSBmYWNlZCBi eSBkaXNhYmxlZCB1c2VycyBvZiByZWFsdGltZQ0KPj4+Pj4+IGVtZXJnZW5jeSBzZXJ2aWNlcy4N Cj4+Pj4+PiANCj4+Pj4+PiBJbiB0aGUgY2FzZSBvZiBhY2Nlc3MgdG8gZW1lcmdlbmN5IHNlcnZp Y2VzIGJ5IHRoZSBkaXNhYmxlZCwgdGhlDQo+Pj4+Pj4gZ29hbCBpcyBub3QgInNlbGVjdGlvbiBv ZiB0aGUgYmVzdC1maXQgbGFuZ3VhZ2UiLCBidXQgcmF0aGVyLA0KPj4+Pj4+IHJvdXRpbmcgb2Yg dGhlIGNhbGwgYW5kIG1lZGlhIHNvIGFzIHRvIHB1bGwgdG9nZXRoZXIgdGhlIHNlcnZpY2VzDQo+ Pj4+Pj4gYmVzdCBmaXR0aW5nIHRoZSBlbWVyZ2VuY3kgc2l0dWF0aW9uIGFuZCB0aGUgZGlzYWJp bGl0aWVzIG9mIHRoZQ0KPj4+Pj4+IGNhbGxlciwgYXMgd2VsbCBhcyB0aGUgY2FwYWJpbGl0aWVz IG9mIHRoZSBkZXZpY2UgYW5kDQo+Pj4+Pj4gaW50ZXJtZWRpYXJpZXMgd2hpY2ggbWF5IHNpdCBi ZXR3ZWVuIHRoZSBjYWxsZXIgYW5kIHRoZSBQU0FQLiAgTm90DQo+Pj4+Pj4gb25seSBhcmUgbWVk aWEgYW5kIGxhbmd1YWdlIGludHJpbnNpY2FsbHkgbGlua2VkLCBidXQgYWxzbywgdGhlDQo+Pj4+ Pj4gd2F5cyBpbiB3aGljaCBjYWxscyBhcmUgcm91dGVkIGlzIGluZmx1ZW5jZWQgYW5kIGluIHNv bWUgY2FzZXMNCj4+Pj4+PiBwcmVzY3JpYmVkIGJ5IHJlZ3VsYXRpb24gYW5kIG5hdGlvbmFsIHN0 YW5kYXJkcy4NCj4+Pj4+PiANCj4+Pj4+PiBTaW1wbHkgcHV0LCBkcmFmdC1nZWxsZW5zLXNsaW0t bmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UgbGFja3MNCj4+Pj4+PiBhcHByb3ByaWF0ZSBjb25z aWRlcmF0aW9uIG9mIHRoZSBwcm9ibGVtIGNvbnRleHQuICBTcGVjaWZ5aW5nIGl0IGFzDQo+Pj4+ Pj4gdGhlIHN0YXJ0aW5nIHBvaW50IGlzIHRoZXJlZm9yZSBpbmFwcHJvcHJpYXRlLiBBcyBhbiBl eGFtcGxlLCB0b2RheQ0KPj4+Pj4+IHRoZSBjYWxsIGZsb3cgZGVzY3JpYmVkIGluIFNlY3Rpb24g NC41IHdvdWxkIG1vc3QgbGlrZWx5IHJlc3VsdCBpbg0KPj4+Pj4+IHJlamVjdGlvbiBvZiB0aGUg dmlkZW8gcG9ydGlvbiBvZiB0aGUgY2FsbCBieSB0aGUgUFNBUCwgbGVhdmluZyB0aGUNCj4+Pj4+ PiBkaXNwYXRjaGVyIHdpdGggbm8gbWVhbnMgb2YgY29tbXVuaWNhdGluZyB3aXRoIHRoZSBoZWFy aW5nLWltcGFpcmVkDQo+Pj4+Pj4gY2FsbGVyLCB0aHVzIGxlYXZpbmcgdGhlIGNhbGxlciB3b3Jz ZSBvZmYgdGhhbiB0aGV5IGFyZSB0b2RheQ0KPj4+Pj4+IGF0dGVtcHRpbmcgdG8gbWFrZSBhbiBl bWVyZ2VuY3kgY2FsbCB3aXRoaW4gdGhlIChjdW1iZXJzb21lIGFuZA0KPj4+Pj4+IGVycm9yL2Rl bGF5LXByb25lKSBWaWRlbyBSZWxheSBTZXJ2aWNlLiAgIEEgZnVsbGVyIGNvbnNpZGVyYXRpb24g b2YNCj4+Pj4+PiB0aGUgcHJvYmxlbSBjb250ZXh0IHdvdWxkIGludm9sdmUgY29uc2lkZXJhdGlv biBvZiBjdXJyZW50DQo+Pj4+Pj4gb3BlcmF0aW9uIG9mIHJlbGF5IHNlcnZpY2VzIGFuZCBwcm9w b3NhbHMgZm9yIHRoZWlyIGV2b2x1dGlvbi4NCj4+Pj4+PiBBdHRlbXB0aW5nIHRvIGRldmVsb3Ag dGhpcyBwcm9ibGVtIGNvbnRleHQgd2l0aGluIGEgV0cgdGhhdCBpcw0KPj4+Pj4+IGFsc28gYXR0 ZW1wdGluZyB0byBkZWFsIHdpdGggbGFuZ3VhZ2Utc2VsZWN0aW9uIGluIGVtYWlsIHdvdWxkIGJl DQo+Pj4+Pj4gZnJ1c3RyYXRpbmcgYXQgYmVzdC4NCj4+Pj4+PiANCj4+Pj4+PiBBIHNlbnNpYmxl IENoYXJ0ZXIgd291bGQgYWxzbyBwcm9iYWJseSBpbmNsdWRlIGxpYWlzb25zIHdpdGgNCj4+Pj4+ PiBkaXNhYmlsaXR5IHJpZ2h0cyBvcmdhbml6YXRpb25zLCBncm91cHMgc3BlY2lmeWluZyB0aGUg b3BlcmF0aW9uIG9mDQo+Pj4+Pj4gcmVsYXkgc2VydmljZXMsIGFuZCBncm91cHMgY29uc2lkZXJp bmcgbmV4dCBzdGVwcyBmb3IgYWNjZXNzIHRvDQo+Pj4+Pj4gZW1lcmdlbmN5IHNlcnZpY2VzLg0K Pj4+Pj4+IA0KPj4+Pj4+PiBGcm9tOiBpZXNnQGlldGYub3JnDQo+Pj4+Pj4+IFRvOiBuZXctd29y a0BpZXRmLm9yZw0KPj4+Pj4+PiBEYXRlOiBGcmksIDI2IEp1biAyMDE1IDA4OjM2OjA1IC0wNzAw DQo+Pj4+Pj4+IFN1YmplY3Q6IFtuZXctd29ya10gV0cgUmV2aWV3OiBTZWxlY3Rpb24gb2YgTGFu Z3VhZ2UgZm9yIEludGVybmV0DQo+Pj4+Pj4+IE1lZGlhIChzbGltKQ0KPj4+Pj4+PiANCj4+Pj4+ Pj4gQSBuZXcgSUVURiB3b3JraW5nIGdyb3VwIGhhcyBiZWVuIHByb3Bvc2VkIGluIHRoZSBBcHBs aWNhdGlvbnMgYW5kDQo+Pj4+Pj4+IFJlYWwtVGltZSBBcmVhLiBUaGUgSUVTRyBoYXMgbm90IG1h ZGUgYW55IGRldGVybWluYXRpb24geWV0LiBUaGUNCj4+Pj4+Pj4gZm9sbG93aW5nIGRyYWZ0IGNo YXJ0ZXIgd2FzIHN1Ym1pdHRlZCwgYW5kIGlzIHByb3ZpZGVkIGZvcg0KPj4+Pj4+PiBpbmZvcm1h dGlvbmFsDQo+Pj4+Pj4+IHB1cnBvc2VzIG9ubHkuIFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMg dG8gdGhlIElFU0cgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+IChpZXNnDQo+Pj4+Pj4+IGF0IGlldGYu b3JnKSBieSAyMDE1LTA3LTA2Lg0KPj4+Pj4+PiANCj4+Pj4+Pj4gU2VsZWN0aW9uIG9mIExhbmd1 YWdlIGZvciBJbnRlcm5ldCBNZWRpYSAoc2xpbSkNCj4+Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+IEN1cnJlbnQgU3RhdHVzOiBQ cm9wb3NlZCBXRw0KPj4+Pj4+PiANCj4+Pj4+Pj4gQXNzaWduZWQgQXJlYSBEaXJlY3RvcjoNCj4+ Pj4+Pj4gQmFycnkgTGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPg0KPj4+Pj4+PiANCj4+ Pj4+Pj4gTWFpbGluZyBsaXN0DQo+Pj4+Pj4+IEFkZHJlc3M6IHNsaW1AaWV0Zi5vcmcNCj4+Pj4+ Pj4gVG8gU3Vic2NyaWJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ns aW0NCj4+Pj4+Pj4gQXJjaGl2ZTogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jy b3dzZS9zbGltLw0KPj4+Pj4+PiANCj4+Pj4+Pj4gQ2hhcnRlcjoNCj4+Pj4+Pj4gDQo+Pj4+Pj4+ IERlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6DQo+Pj4+Pj4+IA0KPj4+Pj4+PiBBIG11dHVh bGx5IGNvbXByZWhlbnNpYmxlIGxhbmd1YWdlIGlzIGhlbHBmdWwgZm9yIGh1bWFuDQo+Pj4+Pj4+ IGNvbW11bmljYXRpb24uDQo+Pj4+Pj4+IFRoaXMgaXMgdHJ1ZSBhY3Jvc3MgYSByYW5nZSBvZiBj aXJjdW1zdGFuY2VzIGFuZCBlbnZpcm9ubWVudHMuIEluDQo+Pj4+Pj4+IGdlbmVyYWwsIHRoZSBw cm9ibGVtIGlzIG1vc3QgYWN1dGUgaW4gc2l0dWF0aW9ucyB3aGVyZSB0aGVyZSBpcyBub3QgYQ0K Pj4+Pj4+PiBjbGVhciBjaG9pY2UgZm9yIGEgc2luZ2xlIGxhbmd1YWdlLCBzdWNoIGFzIGVudmly b25tZW50cyBsYWNraW5nDQo+Pj4+Pj4+IGNvbnRleHR1YWwgb3Igb3V0LW9mLWJhbmQgaW5mb3Jt YXRpb24gcmVnYXJkaW5nIHRoZSBpZGVudGl0eSBvZiB0aGUNCj4+Pj4+Pj4gcGFydGllcyBhbmQg dGhlIGxhbmd1YWdlIHRvIGJlIHVzZWQuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBUaGUgZ3JvdXAgd2ls bCBhZGRyZXNzIHR3byBzcGVjaWZpYyBjYXNlcyB0aGF0IG1vc3QgdXJnZW50bHkgbmVlZCBhDQo+ Pj4+Pj4+IHRlY2huaWNhbCBzb2x1dGlvbjogT25lIHByb2JsZW0gc3BhY2UgaXMgbm9uLXJlYWwt dGltZSBjb21tdW5pY2F0aW9uLA0KPj4+Pj4+PiBzcGVjaWZpY2FsbHkgZW1haWwgZm9yIG9uZS10 by1tYW55IG9yIHdoZXJlIHRoZSBzZXQgb2YgcmVjaXBpZW50cyBpcw0KPj4+Pj4+PiBkeW5hbWlj IG9yIGRpZmZlcmVudCByZWNpcGllbnRzIHJlcXVpcmUgZGlmZmVyZW50IGxhbmd1YWdlczsgdGhl DQo+Pj4+Pj4+IG90aGVyIGlzDQo+Pj4+Pj4+IHJlYWwtdGltZSBjb21tdW5pY2F0aW9uLCBzcGVj aWZpY2FsbHkgZW1lcmdlbmN5IGNhbGxpbmcsIHByZWZlcmFibHkNCj4+Pj4+Pj4gYWxzbw0KPj4+ Pj4+PiB1c2VmdWwgZm9yIG90aGVyIGNhc2VzIHdoZXJlIHRoZSBwYXJ0aWVzIG1heSBub3Qga25v dyBlYWNoIG90aGVyDQo+Pj4+Pj4+IHBlcnNvbmFsbHkgb3Igd2hlcmUgb25lIHBhcnR5IHdpc2hl cyB0byBhY2NvbW1vZGF0ZSBwZW9wbGUgd2l0aA0KPj4+Pj4+PiB2YXJ5aW5nDQo+Pj4+Pj4+IGxh bmd1YWdlIGFuZCBtZWRpYSBuZWVkcy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEluIHRoZSByZWFsLXRp bWUgY29tbXVuaWNhdGlvbiBjYXNlLCBsYW5ndWFnZSBhbmQgbWVkaWEgYXJlDQo+Pj4+Pj4+IGlu dHJpbnNpY2FsbHkNCj4+Pj4+Pj4gbGlua2VkLCBmb3IgZXhhbXBsZSwgc2lnbmVkIGxhbmd1YWdl cyByZXF1aXJlIGEgdmlkZW8gbWVkaWEuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBXaGlsZSB0aGUgdHdv IHVzZSBjYXNlcyBhcmUgaW4gZGlmZmVyZW50IGNvbnRleHRzIChyZWFsIHRpbWUgYW5kDQo+Pj4+ Pj4+IG5vbi1yZWFsLXRpbWUpLCB0aGUgZnVuZGFtZW50YWwgZ29hbCBpcyB0aGUgc2FtZTogdG8g ZW5hYmxlIHNlbGVjdGlvbg0KPj4+Pj4+PiBvZg0KPj4+Pj4+PiB0aGUgYmVzdC1maXQgbGFuZ3Vh Z2UocykgZm9yIGEgc3BlY2lmaWMgc2l0dWF0aW9uLiBTb21lIG9mIHRoZQ0KPj4+Pj4+PiBkZXRh aWxzDQo+Pj4+Pj4+IHdpbGwgYWxzbyBiZSBpbiBjb21tb24gYWNyb3NzIHRoZSBjYXNlcywgZS5n LiwgdGhlIGxhbmd1YWdlIHRhZ3MuDQo+Pj4+Pj4+IEhhdmluZw0KPj4+Pj4+PiBhIHNpbmdsZSBX RyBhZGRyZXNzIGJvdGggY2FzZXMgbWFrZXMgaXQgY2xlYXIgdGhhdCB0aGVzZSBhcmUgdHdvDQo+ Pj4+Pj4+IGFzcGVjdHMNCj4+Pj4+Pj4gb2YgdGhlIHNhbWUgYmFzaWMgcHJvYmxlbS4gQSBzaW5n bGUgV0cgYWxzbyBtYWtlcyBpdCBlYXNpZXIgdG8NCj4+Pj4+Pj4gbWF4aW1pemUNCj4+Pj4+Pj4g c2ltaWxhcml0aWVzIGFuZCBhdm9pZCB1bm5lY2Vzc2FyeSBmcmFnbWVudGF0aW9uIG9mIHRoZSBz b2x1dGlvbnMsDQo+Pj4+Pj4+IGFuZA0KPj4+Pj4+PiBmYWNpbGl0YXRlcyBicm9hZGVyIHJldmll dy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFRoZSBncm91cCB3aWxsIHByb2R1Y2UgdHdvIGRvY3VtZW50 cywgb25lIGZvciBlbWFpbCwgYW5kIG9uZSBmb3INCj4+Pj4+Pj4gcmVhbC10aW1lIGNvbW11bmlj YXRpb25zLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gSW4gdGhlIGVtYWlsIGNhc2UsIHRoZSBncm91cCB3 aWxsIGRldGVybWluZSBhIE1JTUUgYmFzZWQgc29sdXRpb24NCj4+Pj4+Pj4gdGhhdA0KPj4+Pj4+ PiBlbmFibGVzIGEgc2luZ2xlIGVtYWlsIG1lc3NhZ2UgdG8gY29udGFpbiBtdWx0aXBsZSBsYW5n dWFnZSB2ZXJzaW9ucw0KPj4+Pj4+PiBvZg0KPj4+Pj4+PiB0aGUgY29udGVudCwgd2l0aCBwcm92 aXNpb25zIHRvIGhlbHAgY2xpZW50cyBzZWxlY3QgYSBiZXN0IGZpdA0KPj4+Pj4+PiB2ZXJzaW9u Lg0KPj4+Pj4+PiANCj4+Pj4+Pj4gSW4gdGhlIHJlYWwtdGltZSBjb21tdW5pY2F0aW9uIGNhc2Us IHRoZSBncm91cCB3aWxsIHByb2R1Y2UgYQ0KPj4+Pj4+PiBzcGVjaWZpY2F0aW9uIGJhc2VkIG9u IGRyYWZ0LWdlbGxlbnMtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZSwNCj4+Pj4+Pj4g ZW5hYmxpbmcgbmVnb3RpYXRpb24gb2YgYSBodW1hbiBsYW5ndWFnZSBwZXIgbWVkaWEgc3RyZWFt LiBUaGUNCj4+Pj4+Pj4gc3BlY2lmaWNhdGlvbiBtdXN0IGJlIHN1aXRhYmxlIGZvciB1c2UgaW4g ZW1lcmdlbmN5IGNvbW11bmljYXRpb25zIGFzDQo+Pj4+Pj4+IHNwZWNpZmllZCBpbiBSRkMgNjQ0 MyBhbmQgUkZDIDY4ODEgKHdoaWNoIHVzZSBTSVAgYW5kIFNEUCB0bw0KPj4+Pj4+PiBuZWdvdGlh dGUNCj4+Pj4+Pj4gbWVkaWEpOyBpdCBpcyBkZXNpcmFibGUgdG8gYWxzbyBiZSBzdWl0YWJsZSBm b3IgdXNlIGluIG5vbi1lbWVyZ2VuY3kNCj4+Pj4+Pj4gcmVhbC10aW1lIGNvbW11bmljYXRpb25z IHRoYXQgc2hhcmUgdGhlIHNhbWUgY2FsbCBzZXQtdXAgYW5kIG1lZGlhDQo+Pj4+Pj4+IG5lZ290 aWF0aW9uIHByb3RvY29scy4gVGhlIG1lY2hhbmlzbSB3aWxsIHBlcm1pdCB0aGUgY2FsbGVyJ3Mg bWVkaWENCj4+Pj4+Pj4gYW5kDQo+Pj4+Pj4+IGxhbmd1YWdlIG5lZWRzIGFuZCBwcmVmZXJlbmNl cyB0byBiZSBtYXRjaGVkIGFnYWluc3Qgd2hhdCB0aGUgY2FsbGVkDQo+Pj4+Pj4+IHBhcnR5IGlz IGFibGUgdG8gcHJvdmlkZS4gVGhlIG1lY2hhbmlzbSB3aWxsIHBlcm1pdCByZXNvdXJjZXMgKGUu Zy4sDQo+Pj4+Pj4+IHRyYW5zbGF0aW9uLCByZWxheSwgbWVkaWEpIHRvIGJlIGFsbG9jYXRlZCBv ciBlbmdhZ2VkIGFzIGVhcmx5IGFzDQo+Pj4+Pj4+IHBvc3NpYmxlIGluIHRoZSBjYWxsIHNldC11 cCBvciBmb3IgdGhlIGNhbGwgdG8gYmUgcm91dGVkIG9yIGhhbmRsZWQNCj4+Pj4+Pj4gc3BlY2lh bGx5IChlLmcuLCByb3V0ZWQgdG8gYSByZXNvdXJjZSBhYmxlIHRvIHByb3ZpZGUgYSBuZWVkZWQN Cj4+Pj4+Pj4gbGFuZ3VhZ2UNCj4+Pj4+Pj4gYW5kL29yIG1lZGlhKS4gQWx0ZXJuYXRpdmVzIHN1 Y2ggYXMgZG9pbmcgdGhlIG5lZ290aWF0aW9uIGluIFNJUCBoYXZlDQo+Pj4+Pj4+IGJlZW4gdGhv cm91Z2hseSBleHBsb3JlZCBpbiB0aGUgcGFzdCBhbmQgYXJlIG91dCBvZiBzY29wZSAoYWx0aG91 Z2gNCj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+IHNjb3BlIG1pZ2h0IGJlIGV4dGVuZGVkIGFmdGVyIHRo ZSBTRFAgbWVjaGFuaXNtIGhhcyBiZWVuIGFkdmFuY2VkKS4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEJ5 IGFkZGluZyBsYW5ndWFnZSB0byB0aGUgZXhpc3RpbmcgbWVkaWEgbmVnb3RpYXRpb24gbWVjaGFu aXNtIGFzDQo+Pj4+Pj4+IHVzZWQgaW4NCj4+Pj4+Pj4gUkZDIDY0NDMgYW5kIFJGQyA2ODgxLCB0 aGUgZ3JvdXAgY2FuIG1lZXQgdGhlIGJhc2ljIHVzZSBjYXNlcyB3aXRoDQo+Pj4+Pj4+IG1pbmlt YWwgYWRkZWQgY29tcGxleGl0eSBhbmQgYmUgYWJsZSB0byBlbmhhbmNlIGxhdGVyIGZvciBhZGRp dGlvbmFsDQo+Pj4+Pj4+IHVzZQ0KPj4+Pj4+PiBjYXNlcyBhcyBuZWVkZWQuDQo+Pj4+Pj4+IA0K Pj4+Pj4+PiBNaWxlc3RvbmVzOg0KPj4+Pj4+PiBPY3QgMjAxNSAtIFN1Ym1pdCAiTXVsdGlwbGUg TGFuZ3VhZ2UgQ29udGVudCBUeXBlIiB0byB0aGUgSUVTRyAoYmFzZWQNCj4+Pj4+Pj4gb24gZHJh ZnQtdG9ta2luc29uLXNsaW0tbXVsdGlsYW5nY29udGVudCkNCj4+Pj4+Pj4gRmViIDIwMTYgLSBT dWJtaXQgIk5lZ290aWF0aW5nIEh1bWFuIExhbmd1YWdlIGluIFJlYWwtVGltZQ0KPj4+Pj4+PiBD b21tdW5pY2F0aW9ucyIgdG8gdGhlIElFU0cgKGJhc2VkIG9uDQo+Pj4+Pj4+IGRyYWZ0LWdlbGxl bnMtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZSkNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0K Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+Pj4+PiBuZXctd29yayBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gbmV3LXdvcmtAaWV0Zi5vcmcN Cj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXctd29yaw0K Pj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiAtLSANCj4+Pj4+IFJhbmRh bGwgR2VsbGVucw0KPj4+Pj4gT3BpbmlvbnMgYXJlIHBlcnNvbmFsOyAgICBmYWN0cyBhcmUgc3Vz cGVjdDsgICAgSSBzcGVhayBmb3IgbXlzZWxmIG9ubHkNCj4+Pj4+IC0tLS0tLS0tLS0tLS0tIFJh bmRvbWx5IHNlbGVjdGVkIHRhZzogLS0tLS0tLS0tLS0tLS0tDQo+Pj4+PiBKdXN0IGJlY2F1c2Ug eW91IGRvIG5vdCB0YWtlIGFuIGludGVyZXN0IGluIHBvbGl0aWNzIGRvZXNuJ3QgbWVhbg0KPj4+ Pj4gcG9saXRpY3Mgd29uJ3QgdGFrZSBhbmQgaW50ZXJlc3QgaW4geW91LiAgLS1QZXJpY2xlcyAo NDk1LTQyNSBCQykNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4+IEVjcml0QGlldGYub3JnDQo+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+IA0KPiAtLSANCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gR3VubmFyIEhlbGxzdHLD tm0NCj4gT21uaXRvcg0KPiBndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2UNCj4gKzQ2IDcwOCAy MDQgMjg4DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQo= From nobody Tue Jul 7 10:32:08 2015 Return-Path: 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 1467A1ACEE0; Tue, 7 Jul 2015 10:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 IxorGEcAkGPy; Tue, 7 Jul 2015 10:32:02 -0700 (PDT) Received: from BLU004-OMC2S34.hotmail.com (blu004-omc2s34.hotmail.com [65.55.111.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7189D1ACEDB; Tue, 7 Jul 2015 10:32:01 -0700 (PDT) Received: from BLU406-EAS330 ([65.55.111.71]) by BLU004-OMC2S34.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 7 Jul 2015 10:32:00 -0700 X-TMN: [Gon0jczVh2eoeQ6UlOj63UqDF4QAC9cv] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 References: <20150626153605.18943.13946.idtracker@ietfa.amsl.com> <559BE96D.2030502@omnitor.se> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <559BE96D.2030502@omnitor.se> Date: Tue, 7 Jul 2015 10:31:55 -0700 To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= X-OriginalArrivalTime: 07 Jul 2015 17:32:00.0342 (UTC) FILETIME=[D4A09760:01D0B8DA] Archived-At: Cc: "slim@ietf.org" , "ecrit@ietf.org" , "iesg@ietf.org" , "Rosen, Brian" , Randall Gellens , ietf@ietf.org Subject: Re: [Ecrit] [new-work] WG Review: Selection of Language for Internet Media (slim) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 17:32:05 -0000 DQpPbiBKdWwgNywgMjAxNSwgYXQgODowMCBBTSwgR3VubmFyIEhlbGxzdHLDtm0gPGd1bm5hci5o ZWxsc3Ryb21Ab21uaXRvci5zZT4gd3JvdGU6DQo+IA0KPiBJIGRlbGV0ZWQgaWV0ZiBhbmQgaWVz ZyBmcm9tIHRoZSBhZGRyZXNzZXMgYW5kIGFkZGVkIHNsaW0uIEJ1dCB5b3UgYXJlIHJpZ2h0IHRo YXQgdGhpcyBpcyBhIGdlbmVyYWwgc2lwIHRvcGljIGFzIHdlbGwuDQo+IEp1c3QgdGVsbCB3aGVy ZSB3ZSBzaGFsbCBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbi4NCg0KW0JBXSBTaW5jZSBtdWNoIG9m IHRoZSByZXF1aXJlZCBkaXNjdXNzaW9uIHdpbGwgbmVlZCB0byBiZSBhYm91dCB0b3BpY3Mgc3Vj aCBhcyByb3V0aW5nIGFuZCBub3QgbGFuZ3VhZ2UgcHJlZmVyZW5jZXMgaXQgc2VlbXMgdG8gbWUg dGhhdCB0aGVyZSBpcyBhIG5lZWQgZm9yIGFub3RoZXIgdmVudWUgb3RoZXIgdGhhbiBTTElNLg0K DQo+IEFib3V0IHdvcmsgaXRlbXM6IEkgdGhpbmsgc2xpbSBjYW4gY29udGludWUgdG8gY3JlYXRl IGl0cyBwbGFubmVkIG1lZGlhIGFuZCBtb2RhbGl0eSBpbmRpY2F0aW9ucy4NCj4gQnV0IHdvcmsg aXMgbmVlZGVkIG9uIHRoZSByb3V0aW5nIG1lY2hhbmlzbXMgdXNpbmcgU0xJTSBhbmQgb3RoZXIg aW5kaWNhdGlvbnMgdG8gZGVjaWRlIG9uIGNvbm5lY3Rpb24gb2YgdXNlcnMgYW5kIG9wdGlvbmFs bHkgYXNzaXN0aW5nIHNlcnZpY2VzIChzdWNoIGFzIHJlbGF5KS4NCg0KW0JBXSBJIGFncmVlLg0K DQo+IEl0IGlzIGJldHRlciBpZiB0aGUgbWVjaGFuaXNtcyBhcmUgZ2VuZXJhbCwgYW5kIG5vdCBl bWVyZ2VuY3kgc2VydmljZSBzcGVjaWZpYy4NCg0KW0JBXSBJIGFsc28gYWdyZWUgd2l0aCB0aGlz IC0gd2hpY2ggaXMgd2h5IEkgYW0gY29uY2VybmVkIGFib3V0IGZvY3Vzc2luZyBzb2xlbHkgb24g ZW1lcmdlbmN5IHNjZW5hcmlvcy4gVGhlIHNhbWUgaXNzdWUgYXJvc2Ugd2l0aCBsb2NhdGlvbiBy b3V0aW5nIC0gU0lQIGNvbnZleWFuY2Ugd2FzIG5vdCBvbmx5IGFib3V0IGVtZXJnZW5jeSB1c2Vz IGFsdGhvdWdoIHRoYXQgd2FzIGNlcnRhaW5seSBhIGtleSB1c2UgY2FzZS4NCg0KDQo+IEFub3Ro ZXIgcmVhc29uIGlzIHRoYXQgbGFyZ2UgcGFydHMgb2YgdGhlIG1lY2hhbmlzbXMgd2lsbCBiZSB1 c2VkIGFuZCB2ZXJpZmllZCB0byB3b3JrLg0KDQpbQkFdIEluZGVlZCAtIGEgY2FsbCBjZW50ZXIg dXNlIGNhc2UgaXMgcGxhdXNpYmxlIGFzIHdlbGwgLSBhbmQgbWlnaHQgYmUgbW9yZSBsaWtlbHkg dG8gbW90aXZhdGUgYWRkaXRpb24gb2YgdGhlIHJlcXVpcmVkIHJvdXRpbmcgZnVuY3Rpb25hbGl0 eSB0byBjb21wb25lbnRzIHN1Y2ggYXMgU0lQIHByb3hpZXMuDQo+IA0KPiBUaGF0IG1lYW5zIHRo YXQgd2UgZW5kIHVwIHdpdGggcmVjb21tZW5kYXRpb25zIHRvIGhhdmUgYnJpZGdlcyBpbiB2YXJp b3VzIHBsYWNlcyB0byBiZSBhYmxlIHRvIGhhbmRsZSB0aGUgZGlmZmVyZW50IGNhbGwgc2NlbmFy aW9zIG9wdGltYWxseS4gRG8geW91IGFncmVlPw0KDQpbQkFdIFllcywgSSBhZ3JlZSAtIGFuZCBp dCBzZWVtcyBpbXBvcnRhbnQgdG8gZG9jdW1lbnQgdGhlc2UgcHJvYmxlbXMgYW5kIHBvdGVudGlh bCBzb2x1dGlvbnMgc28gdGhhdCB0aGVzZSBwcm9ibGVtcyBkbyBub3Qgc2xpcCB0aHJvdWdoIHRo ZSBjcmFja3MuIA0KDQoNCj4gcmVsYXkgc2VydmljZSB1c2VycyBvZiBzcGVlY2gtdG8tc3BlZWNo IGFuZCBjYXB0aW9uZWQgdGVsZXBob255IHNlcnZpY2VzIGNhbm5vdCBkZXNjcmliZSB0aGVpciBu ZWVkcyB3aXRoIHRoZSBjdXJyZW50IHByb3Bvc2VkIGNvZGluZyBvZiBzbGltLCBhbmQgd291bGQg bGlrZWx5IGJlIGJldHRlciBvZmYgdG8gaGF2ZSBhIHBvc3NpYmlsaXR5IHRvIGp1c3QgcmVxdWVz dCBhbiBhc3Npc3Rpbmcgc2VydmljZSBieSBhIFVSSSBhbmQgYSBzaXAgb3BlcmF0aW9uLg0KDQpb QkFdIEluZGVlZC4gSWYgdGhlIElFVEYgaXMgZ29pbmcgdG8gdGFrZSBvbiB0aGVzZSBraW5kIG9m IHByb2JsZW1zLCBpdCBuZWVkcyB0byB0YWtlIGFjdGlvbnMgdGhhdCB3aWxsIGNvbnRyaWJ1dGUg dG8gc29sdmluZyB0aGVtIGluIHRoZWlyIGVudGlyZXR5LiBUaGF0IG1lYW5zIGNoYXJ0ZXJpbmcg dGhlIHdvcmsgaW4gdGhlIHJpZ2h0IHBsYWNlcyB3aXRoIHRoZSByaWdodCBleHBlcnRpc2UuIFdo aWxlIHRoZSBwcm9wb3NlZCBTTElNIFdHIENoYXJ0ZXIgZG9lcyBhZGRyZXNzIG9uZSBhc3BlY3Qg b2YgdGhlIHByb2JsZW0sIGl0IGxlYXZlcyBtb3N0IG9mIGl0IHVucmVzb2x2ZWQgYW5kIHRoZSBw cm9wb3NlZCBXRyBpcyBub3QgdGhlIHJpZ2h0IHZlbnVlIHRvIGNsb3NlIG9uIHRoZSByZW1haW5k ZXIuDQoNCg0KPiANCj4gVGh1cyBzbGltIGlzIG9ubHkgcGFydCBvZiB0aGUgc29sdXRpb24uIEl0 IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBzb21ld2hlcmUgdG8gZGlzY3VzcyB0aGUgd2hvbGUgcGlj dHVyZSBhbmQgc2V0IHNsaW0gYW5kIHRoZSBvdGhlciBtZWNoYW5pc21zIGluIHRoZWlyIGNvbnRl eHQuDQo+IFdoZXJlPw0KPiANCj4gR3VubmFyDQo+IA0KPiBSb3NlbiwgQnJpYW4gc2tyZXYgZGVu IDIwMTUtMDctMDcgMTQ6NTE6DQo+PiBCdXQgdGhlIGRyYWZ0IGRvZXNu4oCZdCBzdWdnZXN0IHRo YXQgdGhlIGRpcmVjdCBtb2RlbCBzaG91bGQgcmVwbGFjZSB0aGUNCj4+IGN1cnJlbnQgZW1lcmdl bmN5IGNhbGwgcm91dGluZywgaXQgbWVyZWx5IGFsbG93cyBuZXcgY2FwYWJpbGl0eS4gIElmIHRo ZXJlDQo+PiBpcyBhbnkgbGFuZ3VhZ2UgeW91IGZpbmQgdGhhdCBtYWtlcyBpdCBzZWVtIGxpa2Ug ZGlyZWN0IHJvdXRpbmcgc2hvdWxkIGJlDQo+PiBwcmVmZXJyZWQgb3ZlciB0aGUgY3VycmVudCBs b2NhdGlvbiBiYXNlZCByb3V0aW5nLCB3ZSBjYW4gYWRkcmVzcyB0aGF0Lg0KPj4gDQo+PiBPbiB5 b3VyIHNwZWNpZmljIHBvaW50IGFib3V0IG5vdCBiZWluZyBhYmxlIHRvIGRlYWwgd2l0aCBub24t dmlkZW8NCj4+IGVxdWlwcGVkIFBTQVBzLCB3ZSBoYXZlIHBsZW50eSBvZiBtZWNoYW5pc21zIGF2 YWlsYWJsZSB0byByZWFkaWx5DQo+PiBhY2NvbW1vZGF0ZSB0aGF0IHNpdHVhdGlvbi4gIERldmlj ZXMgYXJlIHJlcXVpcmVkIHRvIGZvbGxvdyBleGlzdGluZw0KPj4gcHJhY3RpY2Ugb2YgZm9yd2Fy ZGluZyBjYWxscyB0byB0aGVpciBub3JtYWwgb3V0Ym91bmQgcHJveHksIGFuZCB0aGlzDQo+PiBk cmFmdCBkb2VzbuKAmXQgY2hhbmdlIHRoYXQgYXQgYWxsLiAgV2hhdCBoYXBwZW5zIGFmdGVyIHRo YXQgaXMgY29uZmluZWQgdG8NCj4+IHdoYXQgdGhlIHNlcnZpY2VzIHRoYXQgcHJvdmlkZSByb3V0 aW5nIGZvciBWUlMsIGFuZCB3ZSBjYW4gaGFuZGxlIGxvY2F0aW9uDQo+PiBzZW5zaXRpdmUgaGFu ZGxpbmcgb2Ygc3VjaCBjYWxscy4gIEFsbCA5LTEtMSBjYWxscyBhcmUg4oCcZGlyZWN04oCdIHJv dXRlZCwgaW4NCj4+IHRoYXQgdGhleSByb3V0ZSB0byB0aGUgb3V0Ym91bmQgcHJveHksIHdoaWNo IHJvdXRlcyBiYXNlZCBvbiB0aGUgTG9TVA0KPj4gcXVlcnkgcmVzdWx0LCBhbmQgdGhhdCBpcyBu b3QgbWVkaWEgc2Vuc2l0aXZlLiAgVGhhdCBkZWxpdmVycyB0aGUgY2FsbCB0bw0KPj4gdGhlIHJp Z2h0IGluYm91bmQgcHJveHkgc2VydmVyLCB3aGljaCB0aGVuIGlzIGFibGUgdG8gcm91dGUgYmFz ZWQgb24NCj4+IG1lZGlhLCBpZiBkZXNpcmVkLg0KPj4gDQo+PiBUaGUgd2F5IHdlIGhhbmRsZSBW UlMsIGFuZCBzdGlsbCBnZXQgY2FsbHMgcm91dGVkIGJ5IHRoZSBsb2NhdGlvbiBvZiB0aGUNCj4+ IGNhbGxlciBpcyB0byBoYXZlIHRoZSBWUlMgc2VydmljZSByb3V0ZSB0aGUgY2FsbCBsaWtlIGFu eSBvdGhlciA5LTEtMSBjYWxsDQo+PiB3b3VsZCBiZSByb3V0ZWQsIGJ1dCB0aGV5IGFkZCBhIGhl YWRlciB0aGF0IGluZm9ybXMgdGhlIFBTQVAgdGhhdCBhIENBIGlzDQo+PiBhdmFpbGFibGUuICBU aGUgUFNBUCB0aGVuIGNyZWF0ZXMgYSAzIHdheSB2aWRlby9hdWRpbyBjYWxsIGFtb25nIHRoZSBQ U0FQLA0KPj4gdGhlIGNhbGxlciBhbmQgdGhlIENBLiAgSWYgdGhlIFBTQVAgd2lzaGVzIHRvIHVz ZSBpdHMgb3duIENBLCBpdCBjYW4gZG8NCj4+IHNvLCBidXQgaXQgbmVlZHMgdG8ga25vdyB0aGlz IGlzIGEgVlJTIGNhbGwuICBUaGUgUFNBUCBkb2VzbuKAmXQgbmVlZCB0bw0KPj4gaGFuZGxlIHZp ZGVvLCBzaW5jZSBpZiBpdOKAmXMgbm90IHNlbmRpbmcvcmVjZWl2aW5nIHZpZGVvLCBpdOKAmXMg YSAyIHdheQ0KPj4gdmlkZW8sIDMgd2F5IGF1ZGlvIGNhbGwsIGFuZCBldmVuIGl0cyBicmlkZ2Ug ZG9lc27igJl0IHJlYWxseSBuZWVkIHRvIGJlIGluDQo+PiB0aGUgdmlkZW8gcGF0aC4NCj4+IA0K Pj4gV2UgY2VydGFpbmx5IGNhbiBoYXZlIGVjcml0IHJldmlldyBkcmFmdHMgY29taW5nIG91dCBv ZiB0aGlzIHdvcmsuICBORU5BDQo+PiBhbmQgRUVOQSB3aWxsIGFsc28gcmV2aWV3Lg0KPj4gDQo+ PiBJIGRvbuKAmXQgYmVsaWV2ZSB0aGVyZSBpcyBhIG5lZWQgdG8gaGF2ZSBhbiBlbnRpcmVseSBz ZXBhcmF0ZSBkb2N1bWVudCB0bw0KPj4gaGFuZGxlIHRoZSBlbWVyZ2VuY3kgY2FsbCBmbG93cy4g IFdlIGp1c3QgbmVlZCBhcHByb3ByaWF0ZSByZXZpZXcsIHdoaWNoDQo+PiBJ4oCZbSBzdXJlIHdl IGNhbiBhcnJhbmdlLg0KPj4gDQo+PiBCcmlhbg0KPj4gDQo+Pj4gT24gNy82LzE1LCAxMTozMCBQ TSwgIkJlcm5hcmQgQWJvYmEiIDxiZXJuYXJkX2Fib2JhQGhvdG1haWwuY29tPiB3cm90ZToNCj4+ PiANCj4+PiBJIGFncmVlIHRoYXQgdGhlICJkaXJlY3QiIG1vZGVsIGRlc2NyaWJlZCBpbiB0aGUg ZHJhZnQgaXMgdmVyeQ0KPj4+IHByb2JsZW1hdGljLiAgT25lIG9mIHRoZSBndWlkaW5nIHByaW5j aXBsZXMgb2YgYWNjZXNzaWJpbGl0eSBpcyB0aGF0DQo+Pj4gc2VydmljZXMgbmVlZCB0byBiZSBh dmFpbGFibGUgYXMgd2lkZWx5IGFzIHBvc3NpYmxlIGdpdmVuIFBTQVANCj4+PiBjYXBhYmlsaXRp ZXMuIEF0dGVtcHRpbmcgdG8gcm91dGUgVlJTIGVtZXJnZW5jeSBjYWxscyBkaXJlY3RseSB3aWxs DQo+Pj4gYWN0dWFsbHkgZHJhbWF0aWNhbGx5IHJlZHVjZSB0aGUgYWJpbGl0eSBvZiBkaXNhYmxl ZCB1c2VycyB0byByZWFjaA0KPj4+IGVtZXJnZW5jeSBzZXJ2aWNlcyBzaW5jZSB2aWRlbyBjb3Vs ZCBub3QgYmUgYWNjZXB0ZWQgdW50aWwgdGhlIFBTQVAgaXMNCj4+PiBlcXVpcHBlZCB0byBoYW5k bGUgaXQsIGV2ZW4gaWYgdGhlIGludGVycHJldGF0aW9uIHNlcnZpY2Ugd2VyZSBhYmxlIHRvIGRv DQo+Pj4gc28sIGFuZCBhIGNhbGwgcm91dGVkIHZpYSB0aGUgaW50ZXJwcmV0aW5nIHNlcnZpY2Ug Y291bGQgc3VjY2VlZCB3aXRoDQo+Pj4gZnVsbCBmdW5jdGlvbmFsaXR5Lg0KPj4+IA0KPj4+IFRo ZXNlIGFyZSBleGFjdGx5IHRoZSBraW5kcyBvZiBpc3N1ZXMgdGhhdCB3b3VsZCBiZSBkZWJhdGVk IGFuZCBhZGRyZXNzZWQNCj4+PiB3aXRoaW4gYSBXRyB3aXRoIGFwcHJvcHJpYXRlIFJBSSBmb2N1 cywgYnV0IHdoaWNoIGFyZSBsaWtlbHkgdG8gYmUNCj4+PiBuZWdsZWN0ZWQgaW4gYSBXRyB3aG9z ZSBDaGFydGVyIGNvdmVycyBib3RoIGVtZXJnZW5jeSBzZXJ2aWNlDQo+Pj4gYWNjZXNzaWJpbGl0 eSBpc3N1ZXMgYW5kIGVtYWlsIGxhbmd1YWdlIHNlbGVjdGlvbi4NCj4+PiANCj4+PiBBdCBhIG1p bmltdW0sIEkgd291bGQgbGlrZSB0byBzZWUgYW5vdGhlciB3b3JrIGl0ZW0gcmVsYXRpbmcgdG8g dXNlIG9mDQo+Pj4gdGhlIHByb3Bvc2VkIGxhbmd1YWdlIHNwZWNpZmljYXRpb24sIGluY2x1ZGlu ZyBjYWxsIGZsb3dzLCB3aXRoaW4gYSBncm91cA0KPj4+IHdpdGggZW1lcmdlbmN5IHNlcnZpY2Vz IG9yIFNJUCBleHBlcnRpc2UgKHN1Y2ggYXMgRUNSSVQpLg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+ IA0KPj4+IA0KPj4+PiBPbiBKdWwgNiwgMjAxNSwgYXQgNzoxMyBQTSwgUm9zZW4sIEJyaWFuIDxC cmlhbi5Sb3NlbkBuZXVzdGFyLmJpej4NCj4+Pj4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBXaGlsZSBJ IHRoaW5rIHRoZSDigJxkaXJlY3QgbW9kZWzigJ0gaXMgYWN0dWFsbHkgdmVyeSBwcm9ibGVtYXRp YywgSSB0aGluaw0KPj4+PiB0aGF0IGRyYWZ0IGlzIHF1aXRlIGFwcHJvcHJpYXRlIGZvciB0aGUg YmFzaWMgcHVycG9zZSBvZiBtYWtpbmcgc3VyZSBhDQo+Pj4+IHRyYWluZWQgY2FsbCB0YWtlciBn ZXRzIHRoZSBjYWxsLiAgQW5kLCBvZiBjb3Vyc2UsIGl04oCZcyBhbHNvIHZlcnkgdXNlZnVsDQo+ Pj4+IGZvciBnZW5lcmljIHJvdXRpbmcgb2YgY2FsbHMgZm9yIHdoaWNoIGEgVlJTIGFzIGEg4oCc dHJhbnNjb2RlcuKAnSB3b3VsZCBiZQ0KPj4+PiBhDQo+Pj4+IG11Y2ggYmV0dGVyIHdheSB0byBt YWtlIGEgZ2VuZXJpYyB2aWRlbyBjYWxsIGxvb2sgZGlmZmVyZW50bHkgZnJvbSBhIFZSUw0KPj4+ PiB2aWRlbyBjYWxsLCBhbmQgaW52b2tlIHByb3BlciB0cmVhdG1lbnQuDQo+Pj4+IA0KPj4+PiBJ dOKAmXMgYWxzbyBhIGJldHRlciB3YXkgdG8gYW5ub3VuY2UgYSBWUlMgY2FsbCB0byB0aGUgY2Fs bCB0YWtlci4gIFRvZGF5LA0KPj4+PiB3ZSBkb27igJl0IGtub3cgaXQgZnJvbSBhbnkgb3RoZXIg M3JkIHBhcnR5IGluaXRpYXRlZCB2aWRlbyBjYWxsLg0KPj4+PiANCj4+Pj4gQXMgUmFuZHkgc2F5 cywgd2XigJl2ZSBkaXNjdXNzZWQgdGhlc2UgaXNzdWVzIHdpdGggdGhlIE5FTkEgQWNjZXNzaWJp bGl0eQ0KPj4+PiBncm91cHMgYXMgd2VsbCBhcyB0aGUgRkNDIGFjY2Vzc2liaWxpdHkgY29tbWl0 dGVlIGZvbGtzLiAgV2XigJl2ZSBhbHNvDQo+Pj4+IGJlZW4NCj4+Pj4gZGlzY3Vzc2luZyB0aGUg aXNzdWVzIHdpdGggUFNBUHMgd2hvIGhhdmUgc29tZSBtdWx0aS1saW5ndWFsIGNhbGwNCj4+Pj4g dGFrZXJzLA0KPj4+PiBhbmQgd291bGQgdmVyeSBtdWNoIGFwcHJlY2lhdGUgYmVpbmcgYWJsZSB0 byByb3V0ZSB0byB0aGUgcmlnaHQgcXVldWUuDQo+Pj4+IEFuZCwgb2YgY291cnNlLCBpbXByb3Zp bmcgaG93IFBTQVBzIGhhbmRsZSDigJxMYW5ndWFnZSBMaW5l4oCdIHNlcnZpY2VzIGlzDQo+Pj4+ IG9uZQ0KPj4+PiBvZiB0aGUgYmFzaWMgZ29hbHMgb2YgdGhpcyB3b3JrLiAgVGhlIGRpcmVjdCBt b2RlbCB3b3VsZCBtYWtlIFZSUyBsb29rDQo+Pj4+IGV4YWN0bHkgbGlrZSBMYW5ndWFnZSBMaW5l Lg0KPj4+PiANCj4+Pj4gQnJpYW4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0K Pj4+Pj4gT24gNy82LzE1LCA4OjM1IFBNLCAiUmFuZGFsbCBHZWxsZW5zIiA8cmFuZHlAcXRpLnF1 YWxjb21tLmNvbT4gd3JvdGU6DQo+Pj4+PiANCj4+Pj4+IEhpIEJlcm5hcmQsDQo+Pj4+PiANCj4+ Pj4+IEknZCBsaWtlIHRvIGRpc2N1c3MgeW91ciBjb25jZXJucyBhIGJpdC4gIEkndmUgYWRkZWQg QnJpYW4gUm9zZW4gdG8NCj4+Pj4+IHRoZSBlbWFpbCBhcyBoZSBpcyBjaGFpciBvZiB0aGUgTkcg KGkzKSBhcmNoaXRlY3R1cmUgZ3JvdXAgaW4gTkVOQS4NCj4+Pj4+IA0KPj4+Pj4gSSdtIHRyeWlu ZyB0byB1bmRlcnN0YW5kIHdoeSB5b3UgYmVsaWV2ZSB0aGF0IHRoZSBjYWxsIGZsb3cgaW4gNC41 DQo+Pj4+PiB3b3VsZCByZXN1bHQgaW4gcmVqZWN0aW9uIG9mIHRoZSB2aWRlbyBzdHJlYW0sIHJh dGhlciB0aGFuIHRoZSBQU0FQDQo+Pj4+PiBlbmdhZ2luZyBhbiBpbnRlcnByZXRhdGlvbiBzZXJ2 aWNlLiAgQXMgeW91IHNheSwgd2UgYXJlIHRyeWluZyB0bw0KPj4+Pj4gbW92ZSBmcm9tIHRvZGF5 J3MgbW9kZWwgaW4gd2hpY2ggdGhlIGNhbGxlciBmaXJzdCBjYWxscyB0aGUgcmVsYXkNCj4+Pj4+ IHNlcnZpY2UsIGFuZCB0aGVuIHRoZSByZWxheSBzZXJ2aWNlIGJyaWRnZXMgaW4gdGhlIFBTQVAs IHRvIGEgZGlyZWN0DQo+Pj4+PiBtb2RlbCB3aGVyZSB0aGUgY2FsbGVyIGNhbGxzIDkxMSBkaXJl Y3RseSwgYW5kIHRoZSBQU0FQIGJyaWRnZXMgaW4NCj4+Pj4+IHRoZSByZWxheSBzZXJ2aWNlLiAg T2J2aW91c2x5LCB0aGVyZSBhcmUgZnVuZGluZyBpc3N1ZXMgdGhhdCB3b3VsZA0KPj4+Pj4gbmVl ZCB0byBiZSBoYW5kbGVkIGluIG9yZGVyIGZvciBQU0FQcyB0byBiZSBhYmxlIHRvIGludm9rZSBy ZWxheQ0KPj4+Pj4gc2VydmljZXMsIGJ1dCBib3RoIHRoZSBuZXh0LWdlbiBhbmQgYWNjZXNzaWJp bGl0eSBncm91cHMgaW4gTkVOQSB3YW50DQo+Pj4+PiBhIGRpcmVjdCBtb2RlbCAod2hpY2ggb2Zm ZXJzIG1hbnkgYWR2YW50YWdlcywgaW5jbHVkaW5nIHByaW9yaXR5DQo+Pj4+PiB0cmVhdG1lbnQg YW5kIGxvY2F0aW9uIGRlbGl2ZXJ5KS4gIFRoZSBORU5BIFBvbGljeS1CYXNlZCBSb3V0aW5nDQo+ Pj4+PiAoUEJSKSBmdW5jdGlvbmFsaXR5IHdpdGhpbiBhbiBFU0luZXQgaGFzIHRoZSBhYmlsaXR5 IHRvIHVzZSB0aGUgU0RQDQo+Pj4+PiB3aGVuIG1ha2luZyByb3V0aW5nIGRlY2lzaW9ucyAoaW4g Y2FzZSBQU0FQcyBoYXZlIGNvb3BlcmF0aW9uDQo+Pj4+PiBhZ3JlZW1lbnRzIHdoZXJlIHNvbWUg UFNBUHMgaGFuZGxlIHNvbWUgdHlwZXMgb2YgY2FsbHMgb3Igc29tZQ0KPj4+Pj4gbGFuZ3VhZ2Vz IG9yIG1lZGlhKS4NCj4+Pj4+IA0KPj4+Pj4gVGhlIGRyYWZ0IGFuZCB0aGUgaXNzdWVzIGhhdmUg YmVlbiBkaXNjdXNzZWQgd2l0aCB0aGUgY28tY2hhaXJzIG9mDQo+Pj4+PiB0aGUgTkVOQSBhY2Nl c3NpYmlsaXR5IFdHLCBhbmQgdGhleSBhcmUgc3Ryb25nbHkgaW4gZmF2b3Igb2YgYSBkaXJlY3QN Cj4+Pj4+IG1vZGVsIGZvciBuZXh0LWdlbi4NCj4+Pj4+IA0KPj4+Pj4gSW4gdGhlIFUuUy4sIGVt ZXJnZW5jeSBjYWxsIHJvdXRpbmcgaXMgZmlyc3QgYnkgbG9jYXRpb24sIGFuZCB0aGVuIGJ5DQo+ Pj4+PiBsb2NhbCBydWxlcyAoaWYgYW55KS4gIEZvciBleGFtcGxlLCBpZiBhIGNhbGwgcmVxdWly ZXMgdGV4dCwgdGhlcmUNCj4+Pj4+IG1pZ2h0IGJlIHNvbWUgUFNBUHMgaW4gYSBjb29wZXJhdGlu ZyBncm91cCB0aGF0IHRha2UgdGV4dCBjYWxscyBvbg0KPj4+Pj4gYmVoYWxmIG9mIG90aGVycy4g IExpa2V3aXNlIGlmIHRoZSBjYWxsIHJlcXVlc3RzIGF1ZGlvIG9yIHRleHR1YWwNCj4+Pj4+IFNw YW5pc2guICBJbiBFdXJvcGUsIHZhcmlvdXMgbW9kZWxzIGFyZSB1bmRlciBkaXNjdXNzaW9uLCBp bmNsdWRpbmcNCj4+Pj4+IHNvbWUgaW4gd2hpY2ggYSBjYWxsIG1pZ2h0IGJlIHJvdXRlZCB0byBh IFBTQVAgaW4gYSBjb3VudHJ5IHdoZXJlIHRoZQ0KPj4+Pj4gY2FsbGVyJ3MgbGFuZ3VhZ2UgaXMg bmF0aXZlLiAgVGhlIGRyYWZ0IGFsbG93cyB0aGlzIGZsZXhpYmlsaXR5OiB0aGUNCj4+Pj4+IGNh bGwgY2FuIGJlIHJvdXRlZCB0byBhIHNwZWNpZmljIFBTQVAgKGFuZCBldmVuIGNhbGwgdGFrZXIp IG9yIHRoZQ0KPj4+Pj4gUFNBUCBjYW4gYnJpZGdlIGluIHRyYW5zbGF0aW9uIG9yIHJlbGF5IHNl cnZpY2VzIGF0IHRoZSBzdGFydCBvZiB0aGUNCj4+Pj4+IGNhbGwuDQo+Pj4+PiANCj4+Pj4+IEF0 IDU6MTUgUE0gLTA3MDAgNy8xLzE1LCBCZXJuYXJkIEFib2JhIHdyb3RlOg0KPj4+Pj4gDQo+Pj4+ Pj4gSSBiZWxpZXZlIHRoYXQgdGhpcyBDaGFydGVyIGlzIHBvb3JseSBzdWl0ZWQgdG8gZGV2ZWxv cGluZw0KPj4+Pj4+IHNvbHV0aW9ucyB0byB0aGUgcHJvYmxlbSBmYWNlZCBieSBkaXNhYmxlZCB1 c2VycyBvZiByZWFsdGltZQ0KPj4+Pj4+IGVtZXJnZW5jeSBzZXJ2aWNlcy4NCj4+Pj4+PiANCj4+ Pj4+PiBJbiB0aGUgY2FzZSBvZiBhY2Nlc3MgdG8gZW1lcmdlbmN5IHNlcnZpY2VzIGJ5IHRoZSBk aXNhYmxlZCwgdGhlDQo+Pj4+Pj4gZ29hbCBpcyBub3QgInNlbGVjdGlvbiBvZiB0aGUgYmVzdC1m aXQgbGFuZ3VhZ2UiLCBidXQgcmF0aGVyLA0KPj4+Pj4+IHJvdXRpbmcgb2YgdGhlIGNhbGwgYW5k IG1lZGlhIHNvIGFzIHRvIHB1bGwgdG9nZXRoZXIgdGhlIHNlcnZpY2VzDQo+Pj4+Pj4gYmVzdCBm aXR0aW5nIHRoZSBlbWVyZ2VuY3kgc2l0dWF0aW9uIGFuZCB0aGUgZGlzYWJpbGl0aWVzIG9mIHRo ZQ0KPj4+Pj4+IGNhbGxlciwgYXMgd2VsbCBhcyB0aGUgY2FwYWJpbGl0aWVzIG9mIHRoZSBkZXZp Y2UgYW5kDQo+Pj4+Pj4gaW50ZXJtZWRpYXJpZXMgd2hpY2ggbWF5IHNpdCBiZXR3ZWVuIHRoZSBj YWxsZXIgYW5kIHRoZSBQU0FQLiAgTm90DQo+Pj4+Pj4gb25seSBhcmUgbWVkaWEgYW5kIGxhbmd1 YWdlIGludHJpbnNpY2FsbHkgbGlua2VkLCBidXQgYWxzbywgdGhlDQo+Pj4+Pj4gd2F5cyBpbiB3 aGljaCBjYWxscyBhcmUgcm91dGVkIGlzIGluZmx1ZW5jZWQgYW5kIGluIHNvbWUgY2FzZXMNCj4+ Pj4+PiBwcmVzY3JpYmVkIGJ5IHJlZ3VsYXRpb24gYW5kIG5hdGlvbmFsIHN0YW5kYXJkcy4NCj4+ Pj4+PiANCj4+Pj4+PiBTaW1wbHkgcHV0LCBkcmFmdC1nZWxsZW5zLXNsaW0tbmVnb3RpYXRpbmct aHVtYW4tbGFuZ3VhZ2UgbGFja3MNCj4+Pj4+PiBhcHByb3ByaWF0ZSBjb25zaWRlcmF0aW9uIG9m IHRoZSBwcm9ibGVtIGNvbnRleHQuICBTcGVjaWZ5aW5nIGl0IGFzDQo+Pj4+Pj4gdGhlIHN0YXJ0 aW5nIHBvaW50IGlzIHRoZXJlZm9yZSBpbmFwcHJvcHJpYXRlLiBBcyBhbiBleGFtcGxlLCB0b2Rh eQ0KPj4+Pj4+IHRoZSBjYWxsIGZsb3cgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC41IHdvdWxkIG1v c3QgbGlrZWx5IHJlc3VsdCBpbg0KPj4+Pj4+IHJlamVjdGlvbiBvZiB0aGUgdmlkZW8gcG9ydGlv biBvZiB0aGUgY2FsbCBieSB0aGUgUFNBUCwgbGVhdmluZyB0aGUNCj4+Pj4+PiBkaXNwYXRjaGVy IHdpdGggbm8gbWVhbnMgb2YgY29tbXVuaWNhdGluZyB3aXRoIHRoZSBoZWFyaW5nLWltcGFpcmVk DQo+Pj4+Pj4gY2FsbGVyLCB0aHVzIGxlYXZpbmcgdGhlIGNhbGxlciB3b3JzZSBvZmYgdGhhbiB0 aGV5IGFyZSB0b2RheQ0KPj4+Pj4+IGF0dGVtcHRpbmcgdG8gbWFrZSBhbiBlbWVyZ2VuY3kgY2Fs bCB3aXRoaW4gdGhlIChjdW1iZXJzb21lIGFuZA0KPj4+Pj4+IGVycm9yL2RlbGF5LXByb25lKSBW aWRlbyBSZWxheSBTZXJ2aWNlLiAgIEEgZnVsbGVyIGNvbnNpZGVyYXRpb24gb2YNCj4+Pj4+PiB0 aGUgcHJvYmxlbSBjb250ZXh0IHdvdWxkIGludm9sdmUgY29uc2lkZXJhdGlvbiBvZiBjdXJyZW50 DQo+Pj4+Pj4gb3BlcmF0aW9uIG9mIHJlbGF5IHNlcnZpY2VzIGFuZCBwcm9wb3NhbHMgZm9yIHRo ZWlyIGV2b2x1dGlvbi4NCj4+Pj4+PiBBdHRlbXB0aW5nIHRvIGRldmVsb3AgdGhpcyBwcm9ibGVt IGNvbnRleHQgd2l0aGluIGEgV0cgdGhhdCBpcw0KPj4+Pj4+IGFsc28gYXR0ZW1wdGluZyB0byBk ZWFsIHdpdGggbGFuZ3VhZ2Utc2VsZWN0aW9uIGluIGVtYWlsIHdvdWxkIGJlDQo+Pj4+Pj4gZnJ1 c3RyYXRpbmcgYXQgYmVzdC4NCj4+Pj4+PiANCj4+Pj4+PiBBIHNlbnNpYmxlIENoYXJ0ZXIgd291 bGQgYWxzbyBwcm9iYWJseSBpbmNsdWRlIGxpYWlzb25zIHdpdGgNCj4+Pj4+PiBkaXNhYmlsaXR5 IHJpZ2h0cyBvcmdhbml6YXRpb25zLCBncm91cHMgc3BlY2lmeWluZyB0aGUgb3BlcmF0aW9uIG9m DQo+Pj4+Pj4gcmVsYXkgc2VydmljZXMsIGFuZCBncm91cHMgY29uc2lkZXJpbmcgbmV4dCBzdGVw cyBmb3IgYWNjZXNzIHRvDQo+Pj4+Pj4gZW1lcmdlbmN5IHNlcnZpY2VzLg0KPj4+Pj4+IA0KPj4+ Pj4+PiBGcm9tOiBpZXNnQGlldGYub3JnDQo+Pj4+Pj4+IFRvOiBuZXctd29ya0BpZXRmLm9yZw0K Pj4+Pj4+PiBEYXRlOiBGcmksIDI2IEp1biAyMDE1IDA4OjM2OjA1IC0wNzAwDQo+Pj4+Pj4+IFN1 YmplY3Q6IFtuZXctd29ya10gV0cgUmV2aWV3OiBTZWxlY3Rpb24gb2YgTGFuZ3VhZ2UgZm9yIElu dGVybmV0DQo+Pj4+Pj4+IE1lZGlhIChzbGltKQ0KPj4+Pj4+PiANCj4+Pj4+Pj4gQSBuZXcgSUVU RiB3b3JraW5nIGdyb3VwIGhhcyBiZWVuIHByb3Bvc2VkIGluIHRoZSBBcHBsaWNhdGlvbnMgYW5k DQo+Pj4+Pj4+IFJlYWwtVGltZSBBcmVhLiBUaGUgSUVTRyBoYXMgbm90IG1hZGUgYW55IGRldGVy bWluYXRpb24geWV0LiBUaGUNCj4+Pj4+Pj4gZm9sbG93aW5nIGRyYWZ0IGNoYXJ0ZXIgd2FzIHN1 Ym1pdHRlZCwgYW5kIGlzIHByb3ZpZGVkIGZvcg0KPj4+Pj4+PiBpbmZvcm1hdGlvbmFsDQo+Pj4+ Pj4+IHB1cnBvc2VzIG9ubHkuIFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIElFU0cg bWFpbGluZyBsaXN0DQo+Pj4+Pj4+IChpZXNnDQo+Pj4+Pj4+IGF0IGlldGYub3JnKSBieSAyMDE1 LTA3LTA2Lg0KPj4+Pj4+PiANCj4+Pj4+Pj4gU2VsZWN0aW9uIG9mIExhbmd1YWdlIGZvciBJbnRl cm5ldCBNZWRpYSAoc2xpbSkNCj4+Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+IEN1cnJlbnQgU3RhdHVzOiBQcm9wb3NlZCBXRw0K Pj4+Pj4+PiANCj4+Pj4+Pj4gQXNzaWduZWQgQXJlYSBEaXJlY3RvcjoNCj4+Pj4+Pj4gQmFycnkg TGVpYmEgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPg0KPj4+Pj4+PiANCj4+Pj4+Pj4gTWFpbGlu ZyBsaXN0DQo+Pj4+Pj4+IEFkZHJlc3M6IHNsaW1AaWV0Zi5vcmcNCj4+Pj4+Pj4gVG8gU3Vic2Ny aWJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NsaW0NCj4+Pj4+Pj4g QXJjaGl2ZTogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9zbGltLw0K Pj4+Pj4+PiANCj4+Pj4+Pj4gQ2hhcnRlcjoNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IERlc2NyaXB0aW9u IG9mIFdvcmtpbmcgR3JvdXA6DQo+Pj4+Pj4+IA0KPj4+Pj4+PiBBIG11dHVhbGx5IGNvbXByZWhl bnNpYmxlIGxhbmd1YWdlIGlzIGhlbHBmdWwgZm9yIGh1bWFuDQo+Pj4+Pj4+IGNvbW11bmljYXRp b24uDQo+Pj4+Pj4+IFRoaXMgaXMgdHJ1ZSBhY3Jvc3MgYSByYW5nZSBvZiBjaXJjdW1zdGFuY2Vz IGFuZCBlbnZpcm9ubWVudHMuIEluDQo+Pj4+Pj4+IGdlbmVyYWwsIHRoZSBwcm9ibGVtIGlzIG1v c3QgYWN1dGUgaW4gc2l0dWF0aW9ucyB3aGVyZSB0aGVyZSBpcyBub3QgYQ0KPj4+Pj4+PiBjbGVh ciBjaG9pY2UgZm9yIGEgc2luZ2xlIGxhbmd1YWdlLCBzdWNoIGFzIGVudmlyb25tZW50cyBsYWNr aW5nDQo+Pj4+Pj4+IGNvbnRleHR1YWwgb3Igb3V0LW9mLWJhbmQgaW5mb3JtYXRpb24gcmVnYXJk aW5nIHRoZSBpZGVudGl0eSBvZiB0aGUNCj4+Pj4+Pj4gcGFydGllcyBhbmQgdGhlIGxhbmd1YWdl IHRvIGJlIHVzZWQuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBUaGUgZ3JvdXAgd2lsbCBhZGRyZXNzIHR3 byBzcGVjaWZpYyBjYXNlcyB0aGF0IG1vc3QgdXJnZW50bHkgbmVlZCBhDQo+Pj4+Pj4+IHRlY2hu aWNhbCBzb2x1dGlvbjogT25lIHByb2JsZW0gc3BhY2UgaXMgbm9uLXJlYWwtdGltZSBjb21tdW5p Y2F0aW9uLA0KPj4+Pj4+PiBzcGVjaWZpY2FsbHkgZW1haWwgZm9yIG9uZS10by1tYW55IG9yIHdo ZXJlIHRoZSBzZXQgb2YgcmVjaXBpZW50cyBpcw0KPj4+Pj4+PiBkeW5hbWljIG9yIGRpZmZlcmVu dCByZWNpcGllbnRzIHJlcXVpcmUgZGlmZmVyZW50IGxhbmd1YWdlczsgdGhlDQo+Pj4+Pj4+IG90 aGVyIGlzDQo+Pj4+Pj4+IHJlYWwtdGltZSBjb21tdW5pY2F0aW9uLCBzcGVjaWZpY2FsbHkgZW1l cmdlbmN5IGNhbGxpbmcsIHByZWZlcmFibHkNCj4+Pj4+Pj4gYWxzbw0KPj4+Pj4+PiB1c2VmdWwg Zm9yIG90aGVyIGNhc2VzIHdoZXJlIHRoZSBwYXJ0aWVzIG1heSBub3Qga25vdyBlYWNoIG90aGVy DQo+Pj4+Pj4+IHBlcnNvbmFsbHkgb3Igd2hlcmUgb25lIHBhcnR5IHdpc2hlcyB0byBhY2NvbW1v ZGF0ZSBwZW9wbGUgd2l0aA0KPj4+Pj4+PiB2YXJ5aW5nDQo+Pj4+Pj4+IGxhbmd1YWdlIGFuZCBt ZWRpYSBuZWVkcy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEluIHRoZSByZWFsLXRpbWUgY29tbXVuaWNh dGlvbiBjYXNlLCBsYW5ndWFnZSBhbmQgbWVkaWEgYXJlDQo+Pj4+Pj4+IGludHJpbnNpY2FsbHkN Cj4+Pj4+Pj4gbGlua2VkLCBmb3IgZXhhbXBsZSwgc2lnbmVkIGxhbmd1YWdlcyByZXF1aXJlIGEg dmlkZW8gbWVkaWEuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBXaGlsZSB0aGUgdHdvIHVzZSBjYXNlcyBh cmUgaW4gZGlmZmVyZW50IGNvbnRleHRzIChyZWFsIHRpbWUgYW5kDQo+Pj4+Pj4+IG5vbi1yZWFs LXRpbWUpLCB0aGUgZnVuZGFtZW50YWwgZ29hbCBpcyB0aGUgc2FtZTogdG8gZW5hYmxlIHNlbGVj dGlvbg0KPj4+Pj4+PiBvZg0KPj4+Pj4+PiB0aGUgYmVzdC1maXQgbGFuZ3VhZ2UocykgZm9yIGEg c3BlY2lmaWMgc2l0dWF0aW9uLiBTb21lIG9mIHRoZQ0KPj4+Pj4+PiBkZXRhaWxzDQo+Pj4+Pj4+ IHdpbGwgYWxzbyBiZSBpbiBjb21tb24gYWNyb3NzIHRoZSBjYXNlcywgZS5nLiwgdGhlIGxhbmd1 YWdlIHRhZ3MuDQo+Pj4+Pj4+IEhhdmluZw0KPj4+Pj4+PiBhIHNpbmdsZSBXRyBhZGRyZXNzIGJv dGggY2FzZXMgbWFrZXMgaXQgY2xlYXIgdGhhdCB0aGVzZSBhcmUgdHdvDQo+Pj4+Pj4+IGFzcGVj dHMNCj4+Pj4+Pj4gb2YgdGhlIHNhbWUgYmFzaWMgcHJvYmxlbS4gQSBzaW5nbGUgV0cgYWxzbyBt YWtlcyBpdCBlYXNpZXIgdG8NCj4+Pj4+Pj4gbWF4aW1pemUNCj4+Pj4+Pj4gc2ltaWxhcml0aWVz IGFuZCBhdm9pZCB1bm5lY2Vzc2FyeSBmcmFnbWVudGF0aW9uIG9mIHRoZSBzb2x1dGlvbnMsDQo+ Pj4+Pj4+IGFuZA0KPj4+Pj4+PiBmYWNpbGl0YXRlcyBicm9hZGVyIHJldmlldy4NCj4+Pj4+Pj4g DQo+Pj4+Pj4+IFRoZSBncm91cCB3aWxsIHByb2R1Y2UgdHdvIGRvY3VtZW50cywgb25lIGZvciBl bWFpbCwgYW5kIG9uZSBmb3INCj4+Pj4+Pj4gcmVhbC10aW1lIGNvbW11bmljYXRpb25zLg0KPj4+ Pj4+PiANCj4+Pj4+Pj4gSW4gdGhlIGVtYWlsIGNhc2UsIHRoZSBncm91cCB3aWxsIGRldGVybWlu ZSBhIE1JTUUgYmFzZWQgc29sdXRpb24NCj4+Pj4+Pj4gdGhhdA0KPj4+Pj4+PiBlbmFibGVzIGEg c2luZ2xlIGVtYWlsIG1lc3NhZ2UgdG8gY29udGFpbiBtdWx0aXBsZSBsYW5ndWFnZSB2ZXJzaW9u cw0KPj4+Pj4+PiBvZg0KPj4+Pj4+PiB0aGUgY29udGVudCwgd2l0aCBwcm92aXNpb25zIHRvIGhl bHAgY2xpZW50cyBzZWxlY3QgYSBiZXN0IGZpdA0KPj4+Pj4+PiB2ZXJzaW9uLg0KPj4+Pj4+PiAN Cj4+Pj4+Pj4gSW4gdGhlIHJlYWwtdGltZSBjb21tdW5pY2F0aW9uIGNhc2UsIHRoZSBncm91cCB3 aWxsIHByb2R1Y2UgYQ0KPj4+Pj4+PiBzcGVjaWZpY2F0aW9uIGJhc2VkIG9uIGRyYWZ0LWdlbGxl bnMtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1sYW5ndWFnZSwNCj4+Pj4+Pj4gZW5hYmxpbmcgbmVn b3RpYXRpb24gb2YgYSBodW1hbiBsYW5ndWFnZSBwZXIgbWVkaWEgc3RyZWFtLiBUaGUNCj4+Pj4+ Pj4gc3BlY2lmaWNhdGlvbiBtdXN0IGJlIHN1aXRhYmxlIGZvciB1c2UgaW4gZW1lcmdlbmN5IGNv bW11bmljYXRpb25zIGFzDQo+Pj4+Pj4+IHNwZWNpZmllZCBpbiBSRkMgNjQ0MyBhbmQgUkZDIDY4 ODEgKHdoaWNoIHVzZSBTSVAgYW5kIFNEUCB0bw0KPj4+Pj4+PiBuZWdvdGlhdGUNCj4+Pj4+Pj4g bWVkaWEpOyBpdCBpcyBkZXNpcmFibGUgdG8gYWxzbyBiZSBzdWl0YWJsZSBmb3IgdXNlIGluIG5v bi1lbWVyZ2VuY3kNCj4+Pj4+Pj4gcmVhbC10aW1lIGNvbW11bmljYXRpb25zIHRoYXQgc2hhcmUg dGhlIHNhbWUgY2FsbCBzZXQtdXAgYW5kIG1lZGlhDQo+Pj4+Pj4+IG5lZ290aWF0aW9uIHByb3Rv Y29scy4gVGhlIG1lY2hhbmlzbSB3aWxsIHBlcm1pdCB0aGUgY2FsbGVyJ3MgbWVkaWENCj4+Pj4+ Pj4gYW5kDQo+Pj4+Pj4+IGxhbmd1YWdlIG5lZWRzIGFuZCBwcmVmZXJlbmNlcyB0byBiZSBtYXRj aGVkIGFnYWluc3Qgd2hhdCB0aGUgY2FsbGVkDQo+Pj4+Pj4+IHBhcnR5IGlzIGFibGUgdG8gcHJv dmlkZS4gVGhlIG1lY2hhbmlzbSB3aWxsIHBlcm1pdCByZXNvdXJjZXMgKGUuZy4sDQo+Pj4+Pj4+ IHRyYW5zbGF0aW9uLCByZWxheSwgbWVkaWEpIHRvIGJlIGFsbG9jYXRlZCBvciBlbmdhZ2VkIGFz IGVhcmx5IGFzDQo+Pj4+Pj4+IHBvc3NpYmxlIGluIHRoZSBjYWxsIHNldC11cCBvciBmb3IgdGhl IGNhbGwgdG8gYmUgcm91dGVkIG9yIGhhbmRsZWQNCj4+Pj4+Pj4gc3BlY2lhbGx5IChlLmcuLCBy b3V0ZWQgdG8gYSByZXNvdXJjZSBhYmxlIHRvIHByb3ZpZGUgYSBuZWVkZWQNCj4+Pj4+Pj4gbGFu Z3VhZ2UNCj4+Pj4+Pj4gYW5kL29yIG1lZGlhKS4gQWx0ZXJuYXRpdmVzIHN1Y2ggYXMgZG9pbmcg dGhlIG5lZ290aWF0aW9uIGluIFNJUCBoYXZlDQo+Pj4+Pj4+IGJlZW4gdGhvcm91Z2hseSBleHBs b3JlZCBpbiB0aGUgcGFzdCBhbmQgYXJlIG91dCBvZiBzY29wZSAoYWx0aG91Z2gNCj4+Pj4+Pj4g dGhlDQo+Pj4+Pj4+IHNjb3BlIG1pZ2h0IGJlIGV4dGVuZGVkIGFmdGVyIHRoZSBTRFAgbWVjaGFu aXNtIGhhcyBiZWVuIGFkdmFuY2VkKS4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEJ5IGFkZGluZyBsYW5n dWFnZSB0byB0aGUgZXhpc3RpbmcgbWVkaWEgbmVnb3RpYXRpb24gbWVjaGFuaXNtIGFzDQo+Pj4+ Pj4+IHVzZWQgaW4NCj4+Pj4+Pj4gUkZDIDY0NDMgYW5kIFJGQyA2ODgxLCB0aGUgZ3JvdXAgY2Fu IG1lZXQgdGhlIGJhc2ljIHVzZSBjYXNlcyB3aXRoDQo+Pj4+Pj4+IG1pbmltYWwgYWRkZWQgY29t cGxleGl0eSBhbmQgYmUgYWJsZSB0byBlbmhhbmNlIGxhdGVyIGZvciBhZGRpdGlvbmFsDQo+Pj4+ Pj4+IHVzZQ0KPj4+Pj4+PiBjYXNlcyBhcyBuZWVkZWQuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBNaWxl c3RvbmVzOg0KPj4+Pj4+PiBPY3QgMjAxNSAtIFN1Ym1pdCAiTXVsdGlwbGUgTGFuZ3VhZ2UgQ29u dGVudCBUeXBlIiB0byB0aGUgSUVTRyAoYmFzZWQNCj4+Pj4+Pj4gb24gZHJhZnQtdG9ta2luc29u LXNsaW0tbXVsdGlsYW5nY29udGVudCkNCj4+Pj4+Pj4gRmViIDIwMTYgLSBTdWJtaXQgIk5lZ290 aWF0aW5nIEh1bWFuIExhbmd1YWdlIGluIFJlYWwtVGltZQ0KPj4+Pj4+PiBDb21tdW5pY2F0aW9u cyIgdG8gdGhlIElFU0cgKGJhc2VkIG9uDQo+Pj4+Pj4+IGRyYWZ0LWdlbGxlbnMtc2xpbS1uZWdv dGlhdGluZy1odW1hbi1sYW5ndWFnZSkNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PiBuZXct d29yayBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gbmV3LXdvcmtAaWV0Zi5vcmcNCj4+Pj4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXctd29yaw0KPj4+Pj4gDQo+Pj4+ PiANCj4+Pj4+IC0tIA0KPj4+Pj4gUmFuZGFsbCBHZWxsZW5zDQo+Pj4+PiBPcGluaW9ucyBhcmUg cGVyc29uYWw7ICAgIGZhY3RzIGFyZSBzdXNwZWN0OyAgICBJIHNwZWFrIGZvciBteXNlbGYgb25s eQ0KPj4+Pj4gLS0tLS0tLS0tLS0tLS0gUmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAtLS0tLS0tLS0t LS0tLS0NCj4+Pj4+IEp1c3QgYmVjYXVzZSB5b3UgZG8gbm90IHRha2UgYW4gaW50ZXJlc3QgaW4g cG9saXRpY3MgZG9lc24ndCBtZWFuDQo+Pj4+PiBwb2xpdGljcyB3b24ndCB0YWtlIGFuZCBpbnRl cmVzdCBpbiB5b3UuICAtLVBlcmljbGVzICg0OTUtNDI1IEJDKQ0KPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IEVjcml0IG1haWxpbmcgbGlzdA0K Pj4gRWNyaXRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZWNyaXQNCj4gDQo+IC0tIA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiBHdW5uYXIgSGVsbHN0csO2bQ0KPiBPbW5pdG9yDQo+IGd1bm5hci5oZWxsc3Ry b21Ab21uaXRvci5zZQ0KPiArNDYgNzA4IDIwNCAyODgNCj4gDQo= From nobody Tue Jul 7 11:51:36 2015 Return-Path: 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 528FD1A1BF2 for ; Tue, 7 Jul 2015 11:51:34 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 en57VmFAnP2o for ; Tue, 7 Jul 2015 11:51:32 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B8E31A1F16 for ; Tue, 7 Jul 2015 11:51:32 -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=1436295092; x=1467831092; h=message-id:in-reply-to:references:date:to:from:subject: content-transfer-encoding; bh=fAObdVH7KLwr9GdBDjVC0MLeYhZ58arhatmE3LOcNVM=; b=Drbi2ZPPAEBQjRs9DLtGe6uZtmEi2gfYsVQhI844HfocyNL4rFzZECgB oj5uvkq1BEcvLVOXp9H1f/VYXfjidpxM7izPGGiITU+4ET3VW4bt173N2 ruSF9OZ/Yn7N4nI5lN/OVKOMm2qKVyNFeV+ZSGPFjSqq42Ha6qCVGZiPA E=; X-IronPort-AV: E=McAfee;i="5700,7163,7855"; a="219295352" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jul 2015 11:51:32 -0700 X-IronPort-AV: E=Sophos;i="5.15,425,1432623600"; d="scan'208";a="929721795" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jul 2015 11:51:32 -0700 Received: from ironmsg02-L.qualcomm.com (ironmsg02-L.qualcomm.com [172.30.48.16]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t67IpVGF011054; Tue, 7 Jul 2015 11:51:31 -0700 X-IronPort-AV: E=Sophos;i="5.15,425,1432623600"; d="scan'208";a="471744185" X-ojodefuego: yes Received: from unknown (HELO [99.111.97.136]) ([10.64.161.227]) by ironmsg02-L.qualcomm.com with ESMTP; 07 Jul 2015 11:51:29 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <4206625251104d9b956ef0a5519b086a@BLUPR07MB020.namprd07.prod.outlook.c om> References: <4206625251104d9b956ef0a5519b086a@BLUPR07MB020.namprd07.prod.outlook.c om> X-Mailer: Eudora for Mac OS X Date: Tue, 7 Jul 2015 11:51:25 -0700 To: Chris Santer , "ecrit@ietf.org" From: Randall Gellens 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-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Ecrit] Additional Data 24 Comments X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 18:51:34 -0000 -- My apologies, I just noticed this message from=20 last year, and am not sure if it was ever sent or=20 not. -- Randall Gellens At 6:01 PM +0000 11/7/14, Chris Santer wrote: > After reviewing version 24, our team came up with some new comments: Thanks, I appreciate it. > > =B7 The draft should probably make=20 > 'provided-by' all lower case; in 5.3 it is=20 > 'Provided-By'. Xml tags are case sensitive,=20 > and RFC 4119 shows it in all lower case when=20 > quoting in text (see section 2.2.4). =46ixed in -25. > =B7 The example in draft 24 section 5.3=20 > now shows the 'EmergencyCallDataValue' element=20 > in the geopriv10 namespace, which seems=20 > incorrect. =46ixed in -25. > =B7 There is a 'DataProviderReference'=20 > element defined in the=20 > EmergencyCallData:ProviderInfo namespace -=20 > however it doesn't actually fall within the=20 > ProviderInfoType definition like it does in=20 > other info types, and like it is used in the=20 > examples. This does seem like a problem in the=20 > schema. =46ixed in -25. > =B7 Also not sure if the=20 > 'DataProviderReference' element that is shown=20 > directly in the PIDF-LO 'provided-by' is really=20 > supposed to be there. No, it isn't. Thanks. Fixed in -25. > =B7 The DataProviderContact element is=20 > declared in the schema as an "xc:vcardType";=20 > instead, it should be declared as a type within=20 > the EmergencyCallData:ProviderInfo namespace=20 > that contains a 'vcards' element from the=20 > vcard-4.0 namespace. Specifically note the use=20 > of 'vcards' plural. This is because RFC 6351=20 > explicitly states The element MUST be=20 > present even when only a single vCard is=20 > present in an XML document. The schema in 24=20 > points to the single vCard definition, and most=20 > (but not all) of the examples also show a=20 > single vCard, and this appears to be a=20 > violation of the RFC. > =B7 The SubscriberData element in=20 > EmergencyCallData:SubscriberInfo has the same=20 > problem as DataProviderContact above. > =B7 The schema shows an 'id' element as=20 > mandatory, but not all examples show this=20 > element and I don't see any explanation what=20 > it's for. Section 4.1.2 states that a=20 > 'ProviderID' element is required, but the=20 > schema has minOccurs=3D"0". Several other=20 > elements are in the same boat. I believe these have all been fixed in -25. If=20 you could double-check that no such problems=20 remain, I'd be grateful. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Television is simply automated day-dreaming. --Lee Lovinger, _Quote_, July 30, 1967 From nobody Tue Jul 7 13:30:12 2015 Return-Path: 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 C21BF1A0119 for ; Tue, 7 Jul 2015 13:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 5OcBzov5LGEr for ; Tue, 7 Jul 2015 13:30:09 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2CBD1A00EF for ; Tue, 7 Jul 2015 13:30:08 -0700 (PDT) Received: from [192.168.131.129] ([195.149.223.251]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MGEv5-1ZGdih11c7-00F9sD; Tue, 07 Jul 2015 22:30:00 +0200 Message-ID: <559C36A8.6000206@gmx.net> Date: Tue, 07 Jul 2015 22:29:28 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Randall Gellens , Chris Santer , "ecrit@ietf.org" References: <4206625251104d9b956ef0a5519b086a@BLUPR07MB020.namprd07.prod.outlook.c om> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pvW6TO9JU1rbBIWeKKdux1meX9ANIntSx" X-Provags-ID: V03:K0:u9VcVrRmaRhhZwoXEIK6tA3SHcYAlfyolhQfN0f6UYocmRNsmZt CUYNql7I4RihogYOy50i6l0CNnIYkz431ELMVpPJRZLfG+pYnLl9NqHA2XON2QTKq9n5Q8F 20y/DWkcbllP2tpEO7VuesFWySz1f6bMLee5fKwyZ5FKppjHuX/iEZLHEtXznAcXVj28FZ9 I9u08zDuk9Mu/Fo9AN8qA== X-UI-Out-Filterresults: notjunk:1;V01:K0:u+K9T8KCCno=:18xEylHRDbrVJjvD3tj5Dc DhOIPP325jhYDRlDBLcsQAD33dMV9rcEEKMUzh0cX65/TRiBDZ+V9u8chbwPSGix0J2kxTt58 b9B2sfi69GdiCwxF2dbgua7quuZ5GJP2kJZVLSOhT4UnuYGU0SgJgzYpVSWsB/br0GnPZ416T 8o3TZ54X/ZQ5WhSA2Q4tvPe12j5sqg1HV6jVXry6alL8qfD79EqBiaYHVicjlaA/L3nvmZaS0 mEmSIiMS/FQ6BJbTR/HxzuvzFDjKtq6sbX3/j5vzTHnDBdNI/0w7MffvLcqFshqr0PFXxsYAx /xThvh/XwvHsfx143N239GDYlaUYm0vPq7HLakQOVqKe6umzPcsPGS+49ESqDghMRkUQl341L XiattYb6VvIlJ9fOKq0mMPAtyBRalnXiNexZnVLnuXKlD/2fbEM4/orujmZAkDjcOUjDklZXA lZwjQLnO0vq8NE3gDwGLaj7x/OGfZgRUyHRkIw/1404Wt8OqkCnpO2W4R4FqjswZw0laqrScw dKHxCp5XQbK+spA5j8CQznSWbVbidAc59GfF03W5RZYTe+9BihopjJ1a+M56R1twwL96LsTyR LEE95nxsEmw8oWRyuX8O9XctwoqyMoB+o3F56IeKmSKEc/ii2HCzhimgjh1m3ny5zySbUMQml p4WmQVPFilLW3eTHGc2niHRgAeiBS/YP+S65Fj+/gOyBORw== Archived-At: Subject: Re: [Ecrit] Additional Data 24 Comments X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 20:30:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pvW6TO9JU1rbBIWeKKdux1meX9ANIntSx Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Randy, Hi Chris, On 07/07/2015 08:51 PM, Randall Gellens wrote: >=20 >> =B7 The DataProviderContact element is declared in the schema= >> as an "xc:vcardType"; instead, it should be declared as a type within >> the EmergencyCallData:ProviderInfo namespace that contains a 'vcards' >> element from the vcard-4.0 namespace. Specifically note the use of >> 'vcards' plural. This is because RFC 6351 explicitly states The >> element MUST be present even when only a single vCard is >> present in an XML document. The schema in 24 points to the single >> vCard definition, and most (but not all) of the examples also show a >> single vCard, and this appears to be a violation of the RFC. >> =B7 The SubscriberData element in >> EmergencyCallData:SubscriberInfo has the same problem as >> DataProviderContact above. Your observation is correct, Chris. We are indeed only re-using part of RFC 6351. RFC 6351 indeed says: " A top-level element is used as root. It contains one or more elements, each representing a complete vCard. The element MUST be present even when only a single vCard is present in an XML document. " We did, however, got rid of the element and instead place one or more elements directly as child elements of and . The question for me is whether it matters. Do we want to have an additional element in our instance documents? The problem is that it does not really serve any purpose in our context. In the vcard space it is a bit different since you need to have a top-level element, which is this element but in our case we place the elements in other elements. I am happy to make change the schema and the examples if you guys think it is a good idea. If we don't make that change we need to be explicit about the difference to RFC 6351. >> =B7 The schema shows an 'id' element as mandatory, but not al= l >> examples show this element and I don't see any explanation what it's >> for. =20 In the latest version we don't seem to have that element in there anymore= =2E >> Section 4.1.2 states that a 'ProviderID' element is required, >> but the schema has minOccurs=3D"0". Several other elements are in the= >> same boat.=20 This is fixed with the latest version but it turns out to be really difficult to keep things in sync between the textual description, the XML schemas, and the examples. Thanks for reading through the document so carefully! Ciao Hannes --pvW6TO9JU1rbBIWeKKdux1meX9ANIntSx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVnDaoAAoJEGhJURNOOiAti4AH/jkp/CPazKziDiCeCIz8BXK3 1JbN3hr5uK1VbzoSCzfV+Lo64Nojx+xN4Tm2t0TmtbU42PNUm1onKgTmZddN7h2Y b1uyKpo5un4ZZZiZGNN41BGV6RfR20kNEAwm8m/ooXkk8adfCNPfYXyMowWCF5lw oPtkSn1B+Yn27lJ5V92hInXWO41sC7akNpj1NGtBcQ0D8Flk+jZ4cHklvxQ+zEHJ JYz9mcAfez8ei24Eg5AvnPJTOFeYf5oAzRJQkVFe34xnh16OcAnBHhxAgqD6vh8m pdXgI+cpfKyy+WxzK2apeeZLvtHH1s8te9Tvgigr5xYH2hEHMvH8jZ7212OZ4UY= =8M+c -----END PGP SIGNATURE----- --pvW6TO9JU1rbBIWeKKdux1meX9ANIntSx-- From nobody Tue Jul 7 22:53:57 2015 Return-Path: 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 523071B30EB for ; Tue, 7 Jul 2015 22:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 2Z0guZByxQ0f for ; Tue, 7 Jul 2015 22:53:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B41241B30E6 for ; Tue, 7 Jul 2015 22:53:53 -0700 (PDT) Received: from [192.168.131.129] ([195.149.223.251]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lusmr-1Z45Pj1Sxl-0108fy; Wed, 08 Jul 2015 07:53:34 +0200 Message-ID: <559CBAC5.6020804@gmx.net> Date: Wed, 08 Jul 2015 07:53:09 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: archie cobbs References: <559C36A8.6000206@gmx.net> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xsu88ET8Bc2CNCRKqGCbLcmLQFe90GGWq" X-Provags-ID: V03:K0:oj5SrPoSYF5Ehdh+dRS97KJPeSvRy9fgAi41/P3HCfhcCsVPmKX ZoSanV2YKWU6WiLsJHrerW9a69HBmAJeAV134qmM6ccB72D4Hr2cwgJF7EDvC/pywdctDHL dee76TSSmJyJXR0KQhAeh10PTMpHP81Z0RVHN8ArUlVbHsR31lt2ip+zpvGvrZrNQt7jVwV saslblkRVVAXB/7ibALXA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Q9w8iiErf54=:uubqzjmBSJ6Wjck4zF8uOX 7gV1zoGmiONmK3b4FcvAR+AsxSF/Ft1Qpyq2woXBWRBxVTsMvDuFnF5zvjIKgfep1GZ4Mcr77 46vjYoKOCfjxCpR3N5AA8z6nOoxJk2xoqnY0b8arfqyquhz6JZvy+OxC/16fmtojkqCxUGi1S qttSkW0NJMDWt3K2RM8ekB4ah2LuP+QpLuBJDtztiWeluqid7j02yhCDmt6AHSE0Z0o/khTqz rKCToO5y04PYCS/+MWBFZ3LCpoejxkT7og6gZm2frgBM3IUKJzd+bb7zv/okyGxKDq5936thU vN/7V3FYbdM5hUIGATKPZfDT6jlqShHJQTqupvlLc2J5eKMunhWb+PMXwU5D+keBNWBHm0sRM rZyepJW8p1lmGsVVHNuNKVMaP9Otm8WqYwen8BGsBOkEtQKMsnNa+UYDf/AddY8X+66mOReMN 426dHyTeRCoAMymUmytNY57kLkhDe0JXT7Rwnj/EQxI8Vs0cTuEnXjzJnRKrMrwBD25rKTZTk fH0A2uFl8pAPFWJX8n/D9Q/5x5BaWGbbUaY6XidsM/ikj3WSgB7nArcI73OZhtOd+jeI2JXL1 5siJKG+F/jeimUNnILKZwv73MVtYrxBzbky4F7iavTCtJknbfLxRbAArQFPagj+k8XEma9en3 86Y/YyvYNzJCfMFKd8M0kFee5/O3ZO7Q4xBE2VnZtmoOV+w== Archived-At: Cc: Randall Gellens , "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data 24 Comments X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 05:53:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xsu88ET8Bc2CNCRKqGCbLcmLQFe90GGWq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I agree with you, Archie. I think the current solution is good and, as you said, we are using the differently than RFC 6351 does as a standalone. On 07/08/2015 12:28 AM, archie cobbs wrote: > We've already flip-flopped between and twice, please > let's not change it again. >=20 > It seems clear to me that what that quoted sentence means is that you > should not send an XML document with as the document root > element. This is entirely reasonable, and does not impact usage when > embedding the inside a larger XML document as we are doing. >=20 > -Archie --xsu88ET8Bc2CNCRKqGCbLcmLQFe90GGWq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVnLrGAAoJEGhJURNOOiAtfckH/3VOiADzLEO8dD424J4Rc18A XGEPq6fxC9rHCWlulvFdeJl0kjC5KlGHGehP8k2mF1MGWhZfTyoI7/Byyvf5WK27 1SYgKIWg7taPND3wvmMA3hVcCInNIRUFLy5JZvirrO7sCnblrxwd1N9c1dEPpUnb EMiM0rnsRq9Z4OTLB8QxPFDlyYYaYt01fLqstY4L7Bt7wft3AaCyvvcSeoti+XGW 7zWyRBj82DrQAxJa6PlM3pke9fqwywetewascav0D4ffbgUsVE5MDN2S4OyRw0x1 YHYVc9ueCAt7C+sx05ZEJY7lID1DF5WeGmoCJqc971kxgdz4Ky1RuJ8O/DQnO08= =PYjw -----END PGP SIGNATURE----- --xsu88ET8Bc2CNCRKqGCbLcmLQFe90GGWq-- From archie.cobbs@motorolasolutions.com Tue Jul 7 15:28:44 2015 Return-Path: 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 035041B29C0 for ; Tue, 7 Jul 2015 15:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 kxccX5YQEYC0 for ; Tue, 7 Jul 2015 15:28:42 -0700 (PDT) Received: from mx0b-0019e102.pphosted.com (mx0b-0019e102.pphosted.com [67.231.157.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD6A1A02BE for ; Tue, 7 Jul 2015 15:28:42 -0700 (PDT) Received: from pps.filterd (m0074419.ppops.net [127.0.0.1]) by mx0b-0019e102.pphosted.com (8.15.0.59/8.14.7) with SMTP id t67MP8aY009581 for ; Tue, 7 Jul 2015 17:28:41 -0500 Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by mx0b-0019e102.pphosted.com with ESMTP id 1vgq2xr1n2-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 07 Jul 2015 17:28:41 -0500 Received: by lbbpo10 with SMTP id po10so45467108lbb.3 for ; Tue, 07 Jul 2015 15:28:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4vmDHieOZUC4DZMBhhSdlYVM4mMNV2718kM6Y1XUEV8=; b=bHYcKdgAEOBwNOJQRqpEHfxw/R3EgG+t7xCb2/Z1WSG/4Okk+IzKKvuuQ8Qxc9dHad 7Evj3PAQWMJjYEi//yiiPeYnKoWepk22Y7YCUcA2f1PmC0QXvlPD3xVPiACIsG8LPCPw ndQt+CTFsdhwvbBILASwhsjMykqPhfKh9HsBxgyfAK/WDEZVnl7xvyAA2vXKeJZpPdYJ ZXX770elKVmE3gn7n2dKsYIvXSqNEtFU9NHSuKF5hN1QNXyoFdjcJPvo+U67fc4W8yub laHa2SpTPnyDCX0VXoYvScSR7HhshBd+Z25phl+QPe95lb4F4YMKy76RrKO29OjiwoIh Pv1Q== X-Gm-Message-State: ALoCoQlA1xwHDRUCCyulYPt6AL5YegvtjZQgdW/ofF8A6xwYfO8UhXU5RCNycx77+BU0Ock248XyxpbsCgXSu48VycLu72MkyAMOHkagj60wGr+7L4R/75r92TZSG4qLXPUTrdO65b5v X-Received: by 10.112.30.176 with SMTP id t16mr5586590lbh.30.1436308119712; Tue, 07 Jul 2015 15:28:39 -0700 (PDT) X-Received: by 10.112.30.176 with SMTP id t16mr5586582lbh.30.1436308119597; Tue, 07 Jul 2015 15:28:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.170.140 with HTTP; Tue, 7 Jul 2015 15:28:20 -0700 (PDT) In-Reply-To: <559C36A8.6000206@gmx.net> References: <559C36A8.6000206@gmx.net> From: archie cobbs Date: Tue, 7 Jul 2015 17:28:20 -0500 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a1133b7c841cb0a051a508bd4 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=2 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1506180000 definitions=main-1507070338 Archived-At: X-Mailman-Approved-At: Wed, 08 Jul 2015 08:36:53 -0700 Cc: Randall Gellens , "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data 24 Comments X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 13:54:30 -0000 --001a1133b7c841cb0a051a508bd4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 7, 2015 at 3:29 PM, Hannes Tschofenig wrote: > Hi Randy, Hi Chris, > > On 07/07/2015 08:51 PM, Randall Gellens wrote: > >> 'vcards' plural. This is because RFC 6351 explicitly states The > >> element MUST be present even when only a single vCard is > >> present in an XML document. The schema in 24 points to the single > >> vCard definition, and most (but not all) of the examples also show a > >> single vCard, and this appears to be a violation of the RFC. > >> =C2=B7 The SubscriberData element in > >> EmergencyCallData:SubscriberInfo has the same problem as > >> DataProviderContact above. > > Your observation is correct, Chris. We are indeed only re-using part of > RFC 6351. > > RFC 6351 indeed says: > > " > A top-level element is used as root. It contains one or > more elements, each representing a complete vCard. The > element MUST be present even when only a single vCard is > present in an XML document. > " > We've already flip-flopped between and twice, please let's not change it again. It seems clear to me that what that quoted sentence means is that you should not send an XML document with as the document root element. This is entirely reasonable, and does not impact usage when embedding the inside a larger XML document as we are doing. -Archie --=20 Archie Cobbs Distinguished Member of Technical Staff Emergency CallWorks http://emergencycallworks.com/ O: +205-979-1412 M: +205-907-3599 E: *archie.cobbs@motorolasolutions.com * --001a1133b7c841cb0a051a508bd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 7, 2015 at 3:29 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi Randy, Hi= Chris,

On 07/07/2015 08:51 PM, Randall Gellens wrote:
>> 'vcards' plural.=C2=A0 This is because RFC 6351 explicitly= states The
>> <vcards> element MUST be present even when only a single vCa= rd is
>> present in an XML document.=C2=A0 The schema in 24 points to the s= ingle
>> vCard definition, and most (but not all) of the examples also show= a
>> single vCard, and this appears to be a violation of the RFC.
>>=C2=A0 =C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The SubscriberData e= lement in
>> EmergencyCallData:SubscriberInfo has the same problem as
>> DataProviderContact above.

Your observation is correct, Chris. We are indeed only re-using part of
RFC 6351.

RFC 6351 indeed says:

"
=C2=A0 =C2=A0A top-level <vcards> element is used as root.=C2=A0 It c= ontains one or
=C2=A0 =C2=A0more <vcard> elements, each representing a complete vCar= d.=C2=A0 The
=C2=A0 =C2=A0<vcards> element MUST be present even when only a single= vCard is
=C2=A0 =C2=A0present in an XML document.
"

We've already flip-flopped b= etween <vcard> and <vcards> twice, please let's not change = it again.

It seems clear to me that what that quoted sent= ence means is that you should not send an XML document with <vcard> a= s the document root element. This is entirely reasonable, and does not impa= ct usage when embedding the <vcard> inside a larger XML document as w= e are doing.

-Archie

-- =
<= p style=3D"margin-top:0pt;margin-bottom:0pt;text-align:left;direction:ltr;v= ertical-align:baseline">Archie Cobbs

Dist= inguished Member of Technical Staff
Emerg= ency = CallWorks=C2=A0

<= p style=3D"margin-top:0pt;margin-bottom:0pt;text-align:left;direction:ltr;v= ertical-align:baseline">http://emergencycallworks.com/
O: +205-979-1412

M: +205-9= 07-3599
E: archie.cobbs@motorolasolutions.com<= /p>


--001a1133b7c841cb0a051a508bd4-- From nobody Wed Jul 8 10:30:45 2015 Return-Path: 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 4B3561A1B79; Wed, 8 Jul 2015 10:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 HJGGtqe_2Ukn; Wed, 8 Jul 2015 10:30:40 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD341A1A87; Wed, 8 Jul 2015 10:30:40 -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=1436376640; x=1467912640; h=message-id:date:to:from:subject:cc:mime-version; bh=8/s+ng3AiLM6GjPtQMazDhVV/IrBrky/3ybRgI15w8I=; b=q+Xb+jPxZZjj6381xbyI9eNivnIbKksg9wVlch78qlbOtC/2yA6bOAj0 uAYu+Cc1qS5AzM7KS3xnbBPy5+18OMtLOi7zVE0Sm4lz/DvWrTtXimeee kd91BeNLIpT/7pcgxOub8bTHUd/g/+m3Z0pLhHQhZf+ykFpFz6WgXnqbJ M=; X-IronPort-AV: E=McAfee;i="5700,7163,7856"; a="126852210" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2015 10:30:39 -0700 X-IronPort-AV: E=Sophos;i="5.15,432,1432623600"; d="scan'208";a="955982984" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Jul 2015 10:30:32 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 8 Jul 2015 10:30:31 -0700 Message-ID: X-Mailer: Eudora for Mac OS X Date: Wed, 8 Jul 2015 10:30:30 -0700 To: Bernard Aboba , Brian Rosen , Gunnar Hellstrom , Hannes Tschofenig , Henning Schulzrinne , Ban Al-Bakri , Barry Leiba From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: slim@ietf.org, ecrit@ietf.org Subject: [Ecrit] Time in Prague to discuss SLIM real-time draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 17:30:42 -0000 I'd like to set a time to meet in Prague so that Bernard, Brian, myself, and anyone else interested can talk in depth about the SLIM real-time draft. Would Monday lunch work? If not, please suggest some alternate times. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- You never finish a program, you just stop working on it. From nobody Wed Jul 8 10:39:45 2015 Return-Path: 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 EAD601A1BD1; Wed, 8 Jul 2015 10:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 lA4xKNw33o32; Wed, 8 Jul 2015 10:39:42 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1160C1A1BC8; Wed, 8 Jul 2015 10:39:42 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t68HY5Et020063; Wed, 8 Jul 2015 13:39:28 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1vh5qf89e6-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 08 Jul 2015 13:39:28 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.249]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Wed, 8 Jul 2015 13:39:27 -0400 From: "Rosen, Brian" To: Randall Gellens , Bernard Aboba , Gunnar Hellstrom , Hannes Tschofenig , Henning Schulzrinne , Ban Al-Bakri , Barry Leiba Thread-Topic: Time in Prague to discuss SLIM real-time draft Thread-Index: AQHQuaPQLz9b6vQk6kqhL9Xrn4FEcJ3R1sOA Date: Wed, 8 Jul 2015 17:39:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.33.193.32] Content-Type: text/plain; charset="utf-8" Content-ID: <52EE064A29C0604C88AE22E07BCFB333@neustar.biz> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-08_09:2015-07-08,2015-07-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "slim@ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] Time in Prague to discuss SLIM real-time draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 17:39:43 -0000 SG1tbSwgSSB0aGluayBNb25kYXkgbHVuY2ggd29ya3MgZm9yIG1lIHRoaXMgbWVldGluZyAobm8g bW9yZSBBcHBzIGNoYWlyDQpsdW5jaCkuDQoNCk9uIDcvOC8xNSwgMTozMCBQTSwgIlJhbmRhbGwg R2VsbGVucyIgPHJhbmR5QHF0aS5xdWFsY29tbS5jb20+IHdyb3RlOg0KDQo+SSdkIGxpa2UgdG8g c2V0IGEgdGltZSB0byBtZWV0IGluIFByYWd1ZSBzbyB0aGF0IEJlcm5hcmQsIEJyaWFuLA0KPm15 c2VsZiwgYW5kIGFueW9uZSBlbHNlIGludGVyZXN0ZWQgY2FuIHRhbGsgaW4gZGVwdGggYWJvdXQg dGhlIFNMSU0NCj5yZWFsLXRpbWUgZHJhZnQuICBXb3VsZCBNb25kYXkgbHVuY2ggd29yaz8gIElm IG5vdCwgcGxlYXNlIHN1Z2dlc3QNCj5zb21lIGFsdGVybmF0ZSB0aW1lcy4NCj4NCj4tLSANCj5S YW5kYWxsIEdlbGxlbnMNCj5PcGluaW9ucyBhcmUgcGVyc29uYWw7ICAgIGZhY3RzIGFyZSBzdXNw ZWN0OyAgICBJIHNwZWFrIGZvciBteXNlbGYgb25seQ0KPi0tLS0tLS0tLS0tLS0tIFJhbmRvbWx5 IHNlbGVjdGVkIHRhZzogLS0tLS0tLS0tLS0tLS0tDQo+WW91IG5ldmVyIGZpbmlzaCBhIHByb2dy YW0sIHlvdSBqdXN0IHN0b3Agd29ya2luZyBvbiBpdC4NCg0K From nobody Thu Jul 9 14:31:55 2015 Return-Path: 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 742121A03C7 for ; Thu, 9 Jul 2015 14:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 phtShPBOYJK6 for ; Thu, 9 Jul 2015 14:31:52 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ED7B1A03B3 for ; Thu, 9 Jul 2015 14:31:52 -0700 (PDT) Received: from [216.82.253.147] by server-5.bemta-7.messagelabs.com id D7/1F-08719-648EE955; Thu, 09 Jul 2015 21:31:50 +0000 X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-7.tower-165.messagelabs.com!1436477509!24417137!2 X-Originating-IP: [67.69.230.132] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=bell.ca,-,- X-VirusChecked: Checked Received: (qmail 654 invoked from network); 9 Jul 2015 21:31:50 -0000 Received: from unknown (HELO Tls.exchange.bell.ca) (67.69.230.132) by server-7.tower-165.messagelabs.com with AES256-SHA encrypted SMTP; 9 Jul 2015 21:31:50 -0000 X-CrossPremisesHeadersFilteredBySendConnector: EX13EDGE01-WYN.bell.corp.bce.ca Received: from DG1MBX01-DOR.bell.corp.bce.ca (142.117.209.14) by EX13EDGE01-WYN.bell.corp.bce.ca (198.235.68.40) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 9 Jul 2015 17:28:02 -0400 Received: from DG1MBX01-DOR.bell.corp.bce.ca (2002:8e75:d10e::8e75:d10e) by DG1MBX01-DOR.bell.corp.bce.ca (2002:8e75:d10e::8e75:d10e) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 9 Jul 2015 16:31:34 -0500 Received: from DG1MBX01-DOR.bell.corp.bce.ca ([fe80::203b:bd4d:1db7:f155]) by DG1MBX01-DOR.bell.corp.bce.ca ([fe80::7164:652e:4dc6:420d%19]) with mapi id 15.00.0995.031; Thu, 9 Jul 2015 16:31:34 -0500 From: "Caron, Guy (A162859)" To: "ecrit@ietf.org" Thread-Topic: draft-rosen-ecrit-lost-planned-changes-01 Thread-Index: AdC6jqAhtJHtepFgRMyElLuhZqLMGg== Date: Thu, 9 Jul 2015 21:31:33 +0000 Message-ID: <764960384838414ab6e52182983603ee@DG1MBX01-DOR.bell.corp.bce.ca> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.25.1] Content-Type: multipart/alternative; boundary="_000_764960384838414ab6e52182983603eeDG1MBX01DORbellcorpbcec_" MIME-Version: 1.0 Received-SPF: SoftFail (EX13EDGE01-WYN.bell.corp.bce.ca: domain of transitioning g.caron@bell.ca discourages use of 142.117.209.14 as permitted sender) X-OrganizationHeadersPreserved: EX13EDGE01-WYN.bell.corp.bce.ca Archived-At: Subject: [Ecrit] draft-rosen-ecrit-lost-planned-changes-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 21:31:55 -0000 --_000_764960384838414ab6e52182983603eeDG1MBX01DORbellcorpbcec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi ECRIT, Someone pointed me to the above draft on which, for some reason, I missed = the announcement when it was originally submitted. I read the draft and be= lieve that the proposed mechanism has merits and would improve the current= location validation process. I would appreciate seeing this draft progressed in ECRIT. https://tools.ietf.org/html/draft-rosen-ecrit-lost-planned-changes-01 Thanks, Guy Caron ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ --_000_764960384838414ab6e52182983603eeDG1MBX01DORbellcorpbcec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi ECRIT,

 

Someone pointed me to the abov= e draft on which, for some reason, I missed the announcement when it was o= riginally submitted. I read the draft and believe that the proposed mechan= ism has merits and would improve the current location validation process.

 

I would appreciate seeing this= draft progressed in ECRIT.

 

https://tools.ietf.org= /html/draft-rosen-ecrit-lost-planned-changes-01

 

Thanks,

 

Guy Caron


______________________________________________________________________
= This email has been scanned by the Symantec Email Security.cloud service.<= BR> For more information please visit http://www.symanteccloud.com
______________________________________________________________________
= --_000_764960384838414ab6e52182983603eeDG1MBX01DORbellcorpbcec_-- From nobody Thu Jul 9 15:19:42 2015 Return-Path: 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 7FF141A1B1B for ; Thu, 9 Jul 2015 15:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 fexibL2d1DCc for ; Thu, 9 Jul 2015 15:19:39 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21481A1B17 for ; Thu, 9 Jul 2015 15:19:39 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E74A621AA7 for ; Thu, 9 Jul 2015 18:19:38 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 09 Jul 2015 18:19:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=TlzFYBpha8/lik3f6BuOlnpCk3A=; b=TWsKtu t144/pmx8qyut7LBDgSp+9ESBBoQrFwV6J0mO+zIL1bBjBWD6g1CTkJNC2btuAyN MJ4UdLRpv7NKC/YOdCnhPnbRY6vJKtmt7RZBr1uGiwTjT0VXOZDhMSSE4qOqPhzJ GZovxJbBoNP888z3BT4Gclkig8qkPrgdCCOu4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=TlzFYBpha8/lik3 f6BuOlnpCk3A=; b=TExthHmzE4RrZu68r55y6TDDFPgZNekUbLg/DubX6cwSuxd rBlOjcnY5g3W0Vhptt27JwkLucpdq2WUBhf4RZPC660ns5M+J5eux6/sslDDmCsM GsE98T/cNDwrkx3Nl9L7bEiU6eBxKe+NjlWXw7I8DabV14/WtTs4lwIPx2D0= X-Sasl-enc: AmqJSlAJVy3DD/ffgcK0LeC/2juexrKjOFOrhw2hiZEo 1436480378 Received: from dhcp-171-68-21-99.cisco.com (dhcp-171-68-21-99.cisco.com [171.68.21.99]) by mail.messagingengine.com (Postfix) with ESMTPA id BF4B9C00023; Thu, 9 Jul 2015 18:19:37 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: Date: Thu, 9 Jul 2015 15:19:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> To: Randall Gellens X-Mailer: Apple Mail (2.1878.6) Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 22:19:41 -0000 Hi Randy, Thanks for addressing my comments. I have one follow-up below. On Jun 28, 2015, at 6:53 PM, Randall Gellens = wrote: >>=20 >> Section 4.3.4: >> I'm curious about the kinds of "investigations"=20 >> that PSAPs do and how they have used unique=20 >> device IDs in those investigations -- could you=20 >> explain? At first blush this seems to require=20 >> over-sharing of sensitive data. >=20 > The most common situation that I'm aware of is=20 > repeated false/accidental calls. If there is no=20 > callback number or it isn't usable, the PSAP may=20 > need to try and track down the device by=20 > contacting the service providers in the area. In=20 > the case of handsets without current service,=20 > they may be able to determine who last had=20 > service. =20 How does the user make an emergency call without current service? > There could be other situations where=20 > this might be useful (e.g., a disconnected call=20 > where the call taker believes there is a need for=20 > assistance but was not able to obtain a location=20 > or other information). It would be helpful if the above explanation could be included in the = draft. Given the explanation above, does it really make sense for the device to = be providing this information in addition to the service provider? That = is, the device may have many possible device IDs that it could include, = but it may not know which ones the service provider collects and = correlates to specific users, so it won=92t necessarily know which ones = to provide. Given that all of these IDs can be uniquely identifying in = different contexts, providing multiple IDs that won=92t get used seems = like not the best idea. And if the user is abusing the emergency call = system, he won=92t include these anyway. Are we sure that all of the device types specified actually get used in = this way by PSAPs? E.g., I was curious about whether service providers = track device RFIDs. I also think, as much as I dislike the subscriber privacy indicator = specified in 4.4.1, it should cover this data element as well, = particularly since this element can be inserted by the service provider = without the user knowing. Thanks, Alissa From nobody Thu Jul 9 15:38:53 2015 Return-Path: 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 90C0D1A1B3D for ; Thu, 9 Jul 2015 15:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 ea_pC22_mrjt for ; Thu, 9 Jul 2015 15:38:50 -0700 (PDT) Received: from p01c11o147.mxlogic.net (p01c11o147.mxlogic.net [208.65.144.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAFE31A1B34 for ; Thu, 9 Jul 2015 15:38:49 -0700 (PDT) Received: from unknown [64.58.50.3] (EHLO smtp1.intrado.com) by p01c11o147.mxlogic.net(mxl_mta-8.4.0-1) with ESMTP id 9f7fe955.2b2afd401940.130433.00-423.379425.p01c11o147.mxlogic.net (envelope-from ); Thu, 09 Jul 2015 16:38:49 -0600 (MDT) X-MXL-Hash: 559ef7f95165474e-2027dd96a42453984bc03afa67f968c72719e620 Received: from unknown [64.58.50.3] (EHLO smtp1.intrado.com) by p01c11o147.mxlogic.net(mxl_mta-8.4.0-1) over TLS secured channel with ESMTP id 347fe955.0.128307.00-240.373421.p01c11o147.mxlogic.net (envelope-from ); Thu, 09 Jul 2015 16:35:55 -0600 (MDT) X-MXL-Hash: 559ef74b054e421f-a9863ab760c0f63b94ea29471928e076e1589caf Received: from lmv08-bh01.intrado.com (10.100.104.6) by smtp1.intrado.com (10.100.70.11) with Microsoft SMTP Server id 14.2.347.0; Thu, 9 Jul 2015 16:35:31 -0600 Received: from lmv08-mx01.corp.intrado.pri (10.100.7.7) by mail.intrado.com (192.168.104.4) with Microsoft SMTP Server id 14.2.347.0; Thu, 9 Jul 2015 16:35:41 -0600 Received: from lmv08-mx02.corp.intrado.pri ([::1]) by lmv08-mx01.corp.intrado.pri ([::1]) with mapi; Thu, 9 Jul 2015 16:35:42 -0600 From: "Militeau, Christian" To: "Caron, Guy (A162859)" , "ecrit@ietf.org" Date: Thu, 9 Jul 2015 16:35:41 -0600 Thread-Topic: draft-rosen-ecrit-lost-planned-changes-01 Thread-Index: AdC6jqAhtJHtepFgRMyElLuhZqLMGgACJWTQ Message-ID: <51581CA9D0965243B6931E4CDEDF3E45055F7AA80D@lmv08-mx02.corp.intrado.pri> References: <764960384838414ab6e52182983603ee@DG1MBX01-DOR.bell.corp.bce.ca> In-Reply-To: <764960384838414ab6e52182983603ee@DG1MBX01-DOR.bell.corp.bce.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_51581CA9D0965243B6931E4CDEDF3E45055F7AA80Dlmv08mx02corp_" MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.000.1202-21666.003 X-TM-AS-Result: No--20.565300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.1 cv=PYXrh0Rd c=1 sm=1 tr=0 a=fK0x7wWexdliSyovM0KqDA==] X-AnalysisOut: [:117 a=fK0x7wWexdliSyovM0KqDA==:17 a=eHlaXHVRAAAA:8 a=YlVT] X-AnalysisOut: [AMxIAAAA:8 a=xqWC_Br6kY4A:10 a=zOBTXjUuO1YA:10 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=jhaAWYBLAAAA:8 a=oRS431OqECpOzhI02RsA:9 a=CjuIK1q_] X-AnalysisOut: [8ugA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=8vfMG8SKC60hqT] X-AnalysisOut: [qCVpEA:9 a=d-Q6UasOxTX5ty3U:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4] X-AnalysisOut: [-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10] X-Spam: [F=0.5598802395; CM=0.500; MH=0.559(2015070917); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [64.58.50.3] Archived-At: Subject: Re: [Ecrit] draft-rosen-ecrit-lost-planned-changes-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 22:38:51 -0000 --_000_51581CA9D0965243B6931E4CDEDF3E45055F7AA80Dlmv08mx02corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ECRIT I also support seeing this draft being progressed in ECRIT to improve the l= ocation validation process for emergency services. Thank you in advance for your consideration. Christian Militeau From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Caron, Guy (A16285= 9) Sent: Thursday, July 09, 2015 3:32 PM To: ecrit@ietf.org Subject: [Ecrit] draft-rosen-ecrit-lost-planned-changes-01 Hi ECRIT, Someone pointed me to the above draft on which, for some reason, I missed t= he announcement when it was originally submitted. I read the draft and beli= eve that the proposed mechanism has merits and would improve the current lo= cation validation process. I would appreciate seeing this draft progressed in ECRIT. https://tools.ietf.org/html/draft-rosen-ecrit-lost-planned-changes-01 Thanks, Guy Caron ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ --_000_51581CA9D0965243B6931E4CDEDF3E45055F7AA80Dlmv08mx02corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

ECRIT

 

I also support seeing this draft being progressed in= ECRIT to improve the location validation process for emergency services.

 

= Thank you in advance for your consideration.

 

Christian Militeau

 <= /o:p>

From: Ecrit [mailto:ecri= t-bounces@ietf.org] On Behalf Of Caron, Guy (A162859)
Sent: Thursday, July 09, 2015 3:32 PM
To: ecrit@ietf.org
Subjec= t: [Ecrit] draft-rosen-ecrit-lost-planned-changes-01<= /p>

 

Hi ECRIT,

<= span lang=3DFR-CA> 

Someone pointed me to the above draft on which, for some reason,= I missed the announcement when it was originally submitted. I read the dra= ft and believe that the proposed mechanism has merits and would improve the= current location validation process.

 

I would appreciate seeing this draft progressed in ECRIT.<= o:p>

 

https://tools.= ietf.org/html/draft-rosen-ecrit-lost-planned-changes-01

 

<= p class=3DMsoNormal>Thanks,

 

Guy Caron


______________________________________________________________= ________
This email has been scanned by the Symantec Email Security.clou= d service.
For more information please visit http://www.symanteccloud.com
_________________________= _____________________________________________

= --_000_51581CA9D0965243B6931E4CDEDF3E45055F7AA80Dlmv08mx02corp_-- From nobody Thu Jul 9 18:47:44 2015 Return-Path: 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 1F71D1A21B7 for ; Thu, 9 Jul 2015 18:47:43 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 mrWoxv2t3xon for ; Thu, 9 Jul 2015 18:47:41 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A341A1B9A for ; Thu, 9 Jul 2015 18:47:41 -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=1436492861; x=1468028861; h=message-id:in-reply-to:references:date:to:from:subject: cc; bh=AYMnJTtFin9z2Z21rDMbcBw3oofaBrZOr3DkZib6kfk=; b=OpPLgaGC5HpyGQlpe0YnMqNBOztEOMRxrclUHc+Ch4DhS5YTPlimNLkF VgB2kh74Vo5B3lbbHRFCyQoWLoTqGYdJtJAvi2GHRyTQMdS87Eg+n0RHf k7wO+FFdPXMmO8RGavtbqQNqTFxguxvjd4duu1rr4quBbF2wEQqxlvQ0i s=; X-IronPort-AV: E=McAfee;i="5700,7163,7857"; a="219766187" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2015 18:47:41 -0700 X-IronPort-AV: E=Sophos;i="5.15,443,1432623600"; d="scan'208";a="1010747847" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2015 18:47:41 -0700 Received: from Ironmsg03-R.qualcomm.com (ironmsg03-R.qualcomm.com [172.30.46.17]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t6A1ldk7012185; Thu, 9 Jul 2015 18:47:40 -0700 X-IronPort-AV: E=Sophos;i="5.15,443,1432623600"; d="scan'208";a="957687318" X-ojodefuego: yes Received: from unknown (HELO [99.111.97.136]) ([10.64.162.243]) by Ironmsg03-R.qualcomm.com with ESMTP; 09 Jul 2015 18:47:38 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> X-Mailer: Eudora for Mac OS X Date: Thu, 9 Jul 2015 18:47:37 -0700 To: Alissa Cooper From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 01:47:43 -0000 At 3:19 PM -0700 7/9/15, Alissa Cooper wrote: > Hi Randy, > > Thanks for addressing my comments. I have one follow-up below. Hi Alissa, Thanks very much. Please see in-line. > On Jun 28, 2015, at 6:53 PM, Randall Gellens > wrote: > >>> >>> 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. > > How does the user make an emergency call without current service? It varies by region; for example, in the U.S. and some European countries, telephone companies (cellular and wirelines) are required to provide emergency access (911 or 112) even if the device or landline has no service. So, old cell phones that haven't had service in years can still be used to dial 911 (or 112), and landlines that have been turned off for non-payment can usually still dial 911. The situation with landlines is a little different from cell phones, so there can be a completely dead landline that is unable to dial 911. PSAPs do get lots false calls from old cell phones that parents have given to kids as toys, for example. Or older kids who think it's funny. > > 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). > > It would be helpful if the above explanation could be included in the draft. I have added this. > Given the explanation above, does it really make sense for the > device to be providing this information in addition to the service > provider? That is, the device may have many possible device IDs > that it could include, but it may not know which ones the service > provider collects and correlates to specific users, so it won't > necessarily know which ones to provide. Given that all of these IDs > can be uniquely identifying in different contexts, providing > multiple IDs that won't get used seems like not the best idea. And > if the user is abusing the emergency call system, he won't include > these anyway. An attacker won't include the information (or would include fake information), but a legitimate device that is used by someone playing pranks, or kids as a toy, or someone who does need help and is using a device without service and can't provide any other information, would include information, and in these cases, it's better if the device includes it, since it's not clear what the service provider knows or will provide. > Are we sure that all of the device types specified actually get > used in this way by PSAPs? E.g., I was curious about whether > service providers track device RFIDs. I'm not aware of this being common with consumer devices, but it could happen with specialized devices. > > I also think, as much as I dislike the subscriber privacy indicator > specified in 4.4.1, it should cover this data element as well, > particularly since this element can be inserted by the service > provider without the user knowing. The thing about the subscriber privacy indicator is that it's up to local regulation what elements it covers and what it means. I don't think we can dictate that. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Whenever you find that you are on the side of the majority, it is time to reform. --Mark Twain From nobody Thu Jul 9 19:26:18 2015 Return-Path: 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 320921A870A for ; Thu, 9 Jul 2015 19:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 5rER_HBVGNFY for ; Thu, 9 Jul 2015 19:26:15 -0700 (PDT) Received: from millet.cc.columbia.edu (millet.cc.columbia.edu [128.59.72.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3AE01A86FE for ; Thu, 9 Jul 2015 19:26:15 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by millet.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id t6A2PElS021900 for ; Thu, 9 Jul 2015 22:26:14 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 8796580 for ; Thu, 9 Jul 2015 22:26:14 -0400 (EDT) Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by hazelnut (Postfix) with ESMTP id 6B18081 for ; Thu, 9 Jul 2015 22:26:14 -0400 (EDT) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id t6A2QDpk028293 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 9 Jul 2015 22:26:14 -0400 (EDT) Received: by iggp10 with SMTP id p10so26611027igg.0 for ; Thu, 09 Jul 2015 19:26:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nZ7y5ak0W7LGFTn0nNEL1lF/4tuW+5NvFJzgv4XN/Q8=; b=dkuCVsTgc621bQ3tPJ50flLGYGsM1xrRzmkMk+bPKM170geQ8SgRKAgAGRTP0Qp14a KqWeEqdjplEBigNwK+NpLO+SEhXqWzQxhsaGFjTbc/a084EO2pWMGXqgaJw4PrsydIvc ciwlGzsKtTKDGvtRinHEGqY7YuLEiZsa28T0zL6KjYKnXBNmtoLTrazqMuOFG3XVI/ET hoY6Wht8JEphBEYxttgIq3S8ecmukw7VCMKXUMSPwI2SeHZOUFU2h3WkukzqLgJPoPEE irksHXsoxG3TUcHBBVh172y0OqElEXEZBay6Ec9Mx/zlZnLuRNuDjeEctlJhHVGs59a5 kL1w== X-Gm-Message-State: ALoCoQllNNm1VRNxdS8sCAXzETHs1dKBUWXMSaJ8ujwkxEJYJwVVV6xRDgj21bUoRjtg4XS71q6no/6AUKJumzlUkT8bYeIWbaufOzO2zD8SYq72IHOTVnrldEy1j1Gq3LEGRvNfJBR+ X-Received: by 10.107.154.196 with SMTP id c187mr19351709ioe.64.1436495173822; Thu, 09 Jul 2015 19:26:13 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.154.196 with SMTP id c187mr19351701ioe.64.1436495173762; Thu, 09 Jul 2015 19:26:13 -0700 (PDT) Received: by 10.36.121.131 with HTTP; Thu, 9 Jul 2015 19:26:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Jul 2015 22:26:13 -0400 Message-ID: From: Henning Schulzrinne To: Randall Gellens Content-Type: multipart/alternative; boundary=001a1140e81e8dc6a8051a7c18ca X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Archived-At: Cc: slim@ietf.org, ECRIT , Barry Leiba , Brian Rosen Subject: Re: [Ecrit] Time in Prague to discuss SLIM real-time draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 02:26:17 -0000 --001a1140e81e8dc6a8051a7c18ca Content-Type: text/plain; charset=UTF-8 I'm in Prague Sunday afternoon through Thursday morning, and fairly flexible. Thanks for organizing! On Wed, Jul 8, 2015 at 1:30 PM, Randall Gellens wrote: > I'd like to set a time to meet in Prague so that Bernard, Brian, myself, > and anyone else interested can talk in depth about the SLIM real-time > draft. Would Monday lunch work? If not, please suggest some alternate > times. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > You never finish a program, you just stop working on it. > --001a1140e81e8dc6a8051a7c18ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm in Prague Sunday afternoon through Thursday mornin= g, and fairly flexible. Thanks for organizing!

On Wed, Jul 8, 2015 at 1:30 PM, Randall = Gellens <randy@qti.qualcomm.com> wrote:
I'd like to set a time to meet in Prague so that Ber= nard, Brian, myself, and anyone else interested can talk in depth about the= SLIM real-time draft.=C2=A0 Would Monday lunch work?=C2=A0 If not, please = suggest some alternate times.

--
Randall Gellens
Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak= for myself only
-------------- Randomly selected tag: ---------------
You never finish a program, you just stop working on it.

--001a1140e81e8dc6a8051a7c18ca-- From nobody Fri Jul 10 05:58:36 2015 Return-Path: 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 BD7CF1AC3A0 for ; Fri, 10 Jul 2015 05:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 L_gUY2pZD5Gr for ; Fri, 10 Jul 2015 05:58:32 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A962D1AC39E for ; Fri, 10 Jul 2015 05:58:32 -0700 (PDT) Received: by igrv9 with SMTP id v9so12012852igr.1 for ; Fri, 10 Jul 2015 05:58:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=VVBNFGs02vvTprZNthJu3nAGApLfGJe8ZCOAcB+/6ss=; b=a2lwcGWoxkyX0CvLF+aOO4smbY0fZ5otOPlr+VxfgzlrW6VGO2RQ98/0+rsRGxO958 8pKuxn4DsI3iwWrCMDDkmGAinCx+HfoDhu1SZmM3Gw5sjlJ3qP8p52RrTEwMiYxkx0mZ XEaH5jDYFCMdEbniIWSuIiWV6AgYRRv26/SYakEzFBM1Y8AC1CJWOGKCUOHqE7UPb+uT aDqOXmOYWBLybYQdKFhQI5JrTcs75z/DSCsMrsHorX2z+/BzCHrOl2XtiVqeaetDAwIX oYU70HVC1HyH1vJivYsIr/vRwHt9F0UmGg1hIPgAgqtLM4Lj2r45gtdv8qGLQd485SJA bAzA== X-Gm-Message-State: ALoCoQk4BgFSxYM7GP9WTczFuvHMLVEDObOKNZpkXlZQSZFyPSRZHn7GusJeLsXc4nPI/sceDK/s X-Received: by 10.50.62.20 with SMTP id u20mr3116369igr.54.1436533111976; Fri, 10 Jul 2015 05:58:31 -0700 (PDT) Received: from MLSAW (cpe-74-136-170-54.kya.res.rr.com. [74.136.170.54]) by smtp.gmail.com with ESMTPSA id b9sm5416704ioj.6.2015.07.10.05.58.29 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 10 Jul 2015 05:58:30 -0700 (PDT) From: "Michael Smith" To: Date: Fri, 10 Jul 2015 08:58:28 -0400 Message-ID: <001401d0bb10$1f68d820$5e3a8860$@dss-corp.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01D0BAEE.98573820" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdC7DrAI/bgA//isSNiAMQ+amN5JaA== Content-Language: en-us Archived-At: Subject: Re: [Ecrit] proposed extension to LoST - Validation of Locations Around a Planned Change X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 12:58:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0015_01D0BAEE.98573820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I've read "Validation of Locations Around a Planned Change" (https://tools.ietf.org/html/draft-rosen-ecrit-lost-planned-changes-01). I support completing this work, primarily because I think that the mechanisms proposed would greatly improve efficiency in the location validation process. The current mechanism works, but IMHO, wastes resources by requiring frequent "brute force" validations of the entire dataset. The mechanisms proposed here would also ensure that planned changes take effect earlier that with the current method. I believe the extension proposed in this draft would alleviate some of the inefficiencies I've observed in early NG9-1-1 implementations in the U.S., and would therefore have an immediate positive effect in that context. Michael Smith Chief Technologist, DSS Corp. Co-chair, NENA Agency Systems Committee ------=_NextPart_000_0015_01D0BAEE.98573820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve read “Validation of Locations Around = a Planned Change” = (https://tools.ietf.org/html/draft-rosen-ecrit-lost-planned-changes-01). = I support completing this work, primarily because I think that the = mechanisms proposed would greatly improve efficiency in the location = validation process. The current mechanism works, but IMHO, wastes = resources by requiring frequent “brute force” validations of = the entire dataset. The mechanisms proposed here would also ensure that = planned changes take effect earlier that with the current = method.

 

I believe the extension proposed in this draft would = alleviate some of the inefficiencies I’ve observed in early = NG9-1-1 implementations in the U.S., and would therefore have an = immediate positive effect in that context.

 

Michael Smith
Chief Technologist, DSS = Corp.

Co-chair, NENA Agency Systems = Committee

 

------=_NextPart_000_0015_01D0BAEE.98573820-- From nobody Fri Jul 10 06:09:58 2015 Return-Path: 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 20B241AC3B9; Fri, 10 Jul 2015 06:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 bcF_XetKruQE; Fri, 10 Jul 2015 06:09:47 -0700 (PDT) Received: from BLU004-OMC4S16.hotmail.com (blu004-omc4s16.hotmail.com [65.55.111.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE551AC3B8; Fri, 10 Jul 2015 06:09:47 -0700 (PDT) Received: from BLU406-EAS19 ([65.55.111.135]) by BLU004-OMC4S16.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 10 Jul 2015 06:09:46 -0700 X-TMN: [6JIU5O/m1vU612EeSuQvyITN+eAzLvqe] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail-3F891650-5D6A-4853-BA24-2A4DB499E808" Content-Transfer-Encoding: 7bit From: Bernard Aboba MIME-Version: 1.0 (1.0) Date: Fri, 10 Jul 2015 06:09:44 -0700 References: To: Henning Schulzrinne In-Reply-To: X-OriginalArrivalTime: 10 Jul 2015 13:09:46.0098 (UTC) FILETIME=[B186BD20:01D0BB11] Archived-At: Cc: "slim@ietf.org" , ECRIT , Barry Leiba , Brian Rosen , Randall Gellens Subject: Re: [Ecrit] Time in Prague to discuss SLIM real-time draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 13:09:49 -0000 --Apple-Mail-3F891650-5D6A-4853-BA24-2A4DB499E808 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I will be in Prague from Saturday through Friday. I cannot do Monday lunch b= ut other days are OK. > On Jul 9, 2015, at 7:26 PM, Henning Schulzrinne wrot= e: >=20 > I'm in Prague Sunday afternoon through Thursday morning, and fairly flexib= le. Thanks for organizing! >=20 >> On Wed, Jul 8, 2015 at 1:30 PM, Randall Gellens w= rote: >> I'd like to set a time to meet in Prague so that Bernard, Brian, myself, a= nd anyone else interested can talk in depth about the SLIM real-time draft. = Would Monday lunch work? If not, please suggest some alternate times. >>=20 >> --=20 >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> You never finish a program, you just stop working on it. >=20 --Apple-Mail-3F891650-5D6A-4853-BA24-2A4DB499E808 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+SSB3aWxs IGJlIGluIFByYWd1ZSBmcm9tIFNhdHVyZGF5IHRocm91Z2ggRnJpZGF5LiBJIGNhbm5vdCBkbyBN b25kYXkgbHVuY2ggYnV0IG90aGVyIGRheXMgYXJlIE9LLjxicj48L2Rpdj48ZGl2Pjxicj5PbiBK dWwgOSwgMjAxNSwgYXQgNzoyNiBQTSwgSGVubmluZyBTY2h1bHpyaW5uZSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5lZHUiPmhnc0Bjcy5jb2x1bWJpYS5lZHU8L2E+Jmd0OyB3 cm90ZTo8YnI+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PGRpdiBkaXI9 Imx0ciI+SSdtIGluIFByYWd1ZSBTdW5kYXkgYWZ0ZXJub29uIHRocm91Z2ggVGh1cnNkYXkgbW9y bmluZywgYW5kIGZhaXJseSBmbGV4aWJsZS4gVGhhbmtzIGZvciBvcmdhbml6aW5nITwvZGl2Pjxk aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFdl ZCwgSnVsIDgsIDIwMTUgYXQgMTozMCBQTSwgUmFuZGFsbCBHZWxsZW5zIDxzcGFuIGRpcj0ibHRy Ij4mbHQ7PGEgaHJlZj0ibWFpbHRvOnJhbmR5QHF0aS5xdWFsY29tbS5jb20iIHRhcmdldD0iX2Js YW5rIj5yYW5keUBxdGkucXVhbGNvbW0uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj48Ymxv Y2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3Jk ZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij5JJ2QgbGlrZSB0byBzZXQg YSB0aW1lIHRvIG1lZXQgaW4gUHJhZ3VlIHNvIHRoYXQgQmVybmFyZCwgQnJpYW4sIG15c2VsZiwg YW5kIGFueW9uZSBlbHNlIGludGVyZXN0ZWQgY2FuIHRhbGsgaW4gZGVwdGggYWJvdXQgdGhlIFNM SU0gcmVhbC10aW1lIGRyYWZ0LiZuYnNwOyBXb3VsZCBNb25kYXkgbHVuY2ggd29yaz8mbmJzcDsg SWYgbm90LCBwbGVhc2Ugc3VnZ2VzdCBzb21lIGFsdGVybmF0ZSB0aW1lcy48c3BhbiBjbGFzcz0i SE9FblpiIj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+PGJyPg0KPGJyPg0KLS0gPGJyPg0KUmFuZGFs bCBHZWxsZW5zPGJyPg0KT3BpbmlvbnMgYXJlIHBlcnNvbmFsOyZuYnNwOyAmbmJzcDsgZmFjdHMg YXJlIHN1c3BlY3Q7Jm5ic3A7ICZuYnNwOyBJIHNwZWFrIGZvciBteXNlbGYgb25seTxicj4NCi0t LS0tLS0tLS0tLS0tIFJhbmRvbWx5IHNlbGVjdGVkIHRhZzogLS0tLS0tLS0tLS0tLS0tPGJyPg0K WW91IG5ldmVyIGZpbmlzaCBhIHByb2dyYW0sIHlvdSBqdXN0IHN0b3Agd29ya2luZyBvbiBpdC48 YnI+DQo8L2ZvbnQ+PC9zcGFuPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+DQo8L2Rpdj48 L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-3F891650-5D6A-4853-BA24-2A4DB499E808-- From nobody Fri Jul 10 06:17:00 2015 Return-Path: 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 D3A811AC3A7 for ; Fri, 10 Jul 2015 06:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 caOd8bZuHRmL for ; Fri, 10 Jul 2015 06:16:55 -0700 (PDT) Received: from bin-vsp-out-03.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBE61AC3B9 for ; Fri, 10 Jul 2015 06:16:55 -0700 (PDT) X-Halon-ID: ea802a52-2705-11e5-8f61-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.42] (unknown [87.96.160.92]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Fri, 10 Jul 2015 15:16:46 +0200 (CEST) Message-ID: <559FC5C1.70905@omnitor.se> Date: Fri, 10 Jul 2015 15:16:49 +0200 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Randall Gellens , Bernard Aboba , Brian Rosen , Hannes Tschofenig , Henning Schulzrinne , Ban Al-Bakri , Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: slim@ietf.org, ecrit@ietf.org Subject: Re: [Ecrit] Time in Prague to discuss SLIM real-time draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 13:16:58 -0000 I will sadly not be in Prague, but want to participate remotely. Any time will do. /Gunnar Randall Gellens skrev den 2015-07-08 19:30: > I'd like to set a time to meet in Prague so that Bernard, Brian, > myself, and anyone else interested can talk in depth about the SLIM > real-time draft. Would Monday lunch work? If not, please suggest some > alternate times. > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Fri Jul 10 07:36:55 2015 Return-Path: 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 119D91A9098 for ; Fri, 10 Jul 2015 07:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, TVD_SPACE_RATIO=0.001, 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 X2z2_ICg1e6T for ; Fri, 10 Jul 2015 07:36:52 -0700 (PDT) Received: from webmail.ndaco.org (mail.ndaco.org [66.97.230.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914011A90D1 for ; Fri, 10 Jul 2015 07:36:52 -0700 (PDT) Received: from ACO54MAIL.ndaco.org ([fe80::b961:65f4:be54:a394]) by ACO54MAIL.ndaco.org ([fe80::b961:65f4:be54:a394%10]) with mapi id 14.03.0235.001; Fri, 10 Jul 2015 09:36:56 -0500 From: Jason Horning To: "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-rosen-ecrit-lost-planned-changes-01 Thread-Index: AdC7HVyvO98QHFDETnm9paV991TqnQ== Date: Fri, 10 Jul 2015 14:36:55 +0000 Message-ID: <98B2A42FAA333144B616D2C361B3E1B20ADA132D@ACO54MAIL.ndaco.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.131.164] Content-Type: multipart/alternative; boundary="_000_98B2A42FAA333144B616D2C361B3E1B20ADA132DACO54MAILndacoo_" MIME-Version: 1.0 Archived-At: Subject: [Ecrit] draft-rosen-ecrit-lost-planned-changes-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 14:36:54 -0000 --_000_98B2A42FAA333144B616D2C361B3E1B20ADA132DACO54MAILndacoo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support draft-rosen-ecrit-lost-planned-changes-01 moving forward. --_000_98B2A42FAA333144B616D2C361B3E1B20ADA132DACO54MAILndacoo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support draft-rosen-ecrit-lost-planned-changes-01 = moving forward.

--_000_98B2A42FAA333144B616D2C361B3E1B20ADA132DACO54MAILndacoo_-- From nobody Fri Jul 10 07:53:12 2015 Return-Path: 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 1928A1B2C89; Fri, 10 Jul 2015 07:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 GPiGXxd5cdOA; Fri, 10 Jul 2015 07:53:10 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092171A9166; Fri, 10 Jul 2015 07:53:10 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6AEpfpd009277; Fri, 10 Jul 2015 10:52:58 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1vjduxg6qa-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 10 Jul 2015 10:52:58 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.249]) by stntexhc10.cis.neustar.com ([169.254.4.214]) with mapi id 14.03.0158.001; Fri, 10 Jul 2015 10:52:57 -0400 From: "Rosen, Brian" To: Randall Gellens , Bernard Aboba , Henning Schulzrinne Thread-Topic: Time in Prague to discuss SLIM real-time draft Thread-Index: AQHQurfKLz9b6vQk6kqhL9Xrn4FEcJ3U8P8AgAAcUgD//71wAA== Date: Fri, 10 Jul 2015 14:52:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.33.193.32] Content-Type: text/plain; charset="utf-8" Content-ID: <834A66592C2F934B8B81E679CD37947E@neustar.biz> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-10_07:2015-07-10,2015-07-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "slim@ietf.org" , ECRIT , Barry Leiba Subject: Re: [Ecrit] Time in Prague to discuss SLIM real-time draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 14:53:11 -0000 SeKAmWQgbGlrZSB0byBnbyB0byBjbHVlLCBidXQgSSBjYW4gc2tpcCBpdC4gIFR1ZXNkYXkgbHVu Y2ggd291bGQgd29yay4NCg0KT24gNy8xMC8xNSwgMTA6NTEgQU0sICJSYW5kYWxsIEdlbGxlbnMi IDxyYW5keUBxdGkucXVhbGNvbW0uY29tPiB3cm90ZToNCg0KPldvdWxkIHRoZSBmaXJzdCBhZnRl cm5vb24gc2Vzc2lvbiAoc3RhcnRzIGF0IDE6MDApIG9uIE1vbmRheSB3b3JrPw0KPg0KPkF0IDY6 MDkgQU0gLTA3MDAgNy8xMC8xNSwgQmVybmFyZCBBYm9iYSB3cm90ZToNCj4NCj4+ICBJIHdpbGwg YmUgaW4gUHJhZ3VlIGZyb20gU2F0dXJkYXkgdGhyb3VnaCBGcmlkYXkuIEkgY2Fubm90IGRvDQo+ PiBNb25kYXkgbHVuY2ggYnV0IG90aGVyIGRheXMgYXJlIE9LLg0KPj4NCj4+DQo+PiAgT24gSnVs IDksIDIwMTUsIGF0IDc6MjYgUE0sIEhlbm5pbmcgU2NodWx6cmlubmUNCj4+IDw8bWFpbHRvOmhn c0Bjcy5jb2x1bWJpYS5lZHU+aGdzQGNzLmNvbHVtYmlhLmVkdT4gd3JvdGU6DQo+Pg0KPj4+ICBJ J20gaW4gUHJhZ3VlIFN1bmRheSBhZnRlcm5vb24gdGhyb3VnaCBUaHVyc2RheSBtb3JuaW5nLCBh bmQNCj4+PiBmYWlybHkgZmxleGlibGUuIFRoYW5rcyBmb3Igb3JnYW5pemluZyENCj4+Pg0KPj4+ ICBPbiBXZWQsIEp1bCA4LCAyMDE1IGF0IDE6MzAgUE0sIFJhbmRhbGwgR2VsbGVucw0KPj4+IDw8 bWFpbHRvOnJhbmR5QHF0aS5xdWFsY29tbS5jb20+cmFuZHlAcXRpLnF1YWxjb21tLmNvbT4gd3Jv dGU6DQo+Pj4NCj4+PiAgSSdkIGxpa2UgdG8gc2V0IGEgdGltZSB0byBtZWV0IGluIFByYWd1ZSBz byB0aGF0IEJlcm5hcmQsIEJyaWFuLA0KPj4+IG15c2VsZiwgYW5kIGFueW9uZSBlbHNlIGludGVy ZXN0ZWQgY2FuIHRhbGsgaW4gZGVwdGggYWJvdXQgdGhlDQo+Pj4gU0xJTSByZWFsLXRpbWUgZHJh ZnQuICBXb3VsZCBNb25kYXkgbHVuY2ggd29yaz8gIElmIG5vdCwgcGxlYXNlDQo+Pj4gc3VnZ2Vz dCBzb21lIGFsdGVybmF0ZSB0aW1lcy4NCj4+Pg0KPj4+ICAtLQ0KPj4+ICBSYW5kYWxsIEdlbGxl bnMNCj4+PiAgT3BpbmlvbnMgYXJlIHBlcnNvbmFsOyAgICBmYWN0cyBhcmUgc3VzcGVjdDsgICAg SSBzcGVhayBmb3IgbXlzZWxmDQo+Pj5vbmx5DQo+Pj4gIC0tLS0tLS0tLS0tLS0tIFJhbmRvbWx5 IHNlbGVjdGVkIHRhZzogLS0tLS0tLS0tLS0tLS0tDQo+Pj4gIFlvdSBuZXZlciBmaW5pc2ggYSBw cm9ncmFtLCB5b3UganVzdCBzdG9wIHdvcmtpbmcgb24gaXQuDQo+DQo+DQo+DQo+LS0gDQo+UmFu ZGFsbCBHZWxsZW5zDQo+T3BpbmlvbnMgYXJlIHBlcnNvbmFsOyAgICBmYWN0cyBhcmUgc3VzcGVj dDsgICAgSSBzcGVhayBmb3IgbXlzZWxmIG9ubHkNCj4tLS0tLS0tLS0tLS0tLSBSYW5kb21seSBz ZWxlY3RlZCB0YWc6IC0tLS0tLS0tLS0tLS0tLQ0KPkhvd2UncyBMYXc6DQo+ICAgIEV2ZXJ5b25l IGhhcyBhIHNjaGVtZSB0aGF0IHdpbGwgbm90IHdvcmsuDQoNCg== From nobody Fri Jul 10 08:12:36 2015 Return-Path: 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 67B3B1A9240; Fri, 10 Jul 2015 08:12:31 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 Ub3WpNw52-su; Fri, 10 Jul 2015 08:12:29 -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 908501A923E; Fri, 10 Jul 2015 08:12:29 -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=1436541149; x=1468077149; h=message-id:in-reply-to:references:date:to:from:subject: cc; bh=aFqaMUCqwcQBWGUeyN6Xw+/6MHhFb8xv7XFW2mUK6mA=; b=l6HwZlBYzX5o/bcEsHuvY4/JJTx1eCCLmm4XpXhgAQBoul236siEhuCm bh99LKSn972raUWKVhFAKEyhhqhNoESYThJck5G52QP8SyDrBl1SdyBaI KbJIFJx4icaPTU5TLWPCfhB1qKwk/Qi/T7SR6/uKLOg8EC7eoXvX/F6cZ Q=; X-IronPort-AV: E=McAfee;i="5700,7163,7857"; a="93512995" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2015 08:12:29 -0700 X-IronPort-AV: E=Sophos;i="5.15,447,1432623600"; d="scan'208";a="932479624" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2015 08:11:48 -0700 Received: from Ironmsg04-L.qualcomm.com (ironmsg04-L.qualcomm.com [172.30.48.19]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t6AFBkih030598; Fri, 10 Jul 2015 08:11:47 -0700 X-IronPort-AV: E=Sophos;i="5.15,447,1432623600"; d="scan'208";a="932479000" X-ojodefuego: yes Received: from unknown (HELO [99.111.97.136]) ([10.64.162.243]) by Ironmsg04-L.qualcomm.com with ESMTP; 10 Jul 2015 08:09:00 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Fri, 10 Jul 2015 08:08:59 -0700 To: "Rosen, Brian" , Bernard Aboba , Henning Schulzrinne From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: "slim@ietf.org" , ECRIT , Barry Leiba Subject: Re: [Ecrit] [Slim] Time in Prague to discuss SLIM real-time draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 15:12:31 -0000 Tuesday lunch is the email work. If the others can make Monday first afternoon session, let's do that. At 2:52 PM +0000 7/10/15, Brian Rosen wrote: > I'd like to go to clue, but I can skip it. Tuesday lunch would work. > > On 7/10/15, 10:51 AM, "Randall Gellens" wrote: > >>Would the first afternoon session (starts at 1:00) on Monday work? >> >>At 6:09 AM -0700 7/10/15, Bernard Aboba wrote: >> >>> I will be in Prague from Saturday through Friday. I cannot do >>> Monday lunch but other days are OK. >>> >>> >>> On Jul 9, 2015, at 7:26 PM, Henning Schulzrinne >>> <hgs@cs.columbia.edu> wrote: >>> >>>> I'm in Prague Sunday afternoon through Thursday morning, and >>>> fairly flexible. Thanks for organizing! >>>> >>>> On Wed, Jul 8, 2015 at 1:30 PM, Randall Gellens >>>> <randy@qti.qualcomm.com> wrote: >>>> >>>> I'd like to set a time to meet in Prague so that Bernard, Brian, >>>> myself, and anyone else interested can talk in depth about the >>>> SLIM real-time draft. Would Monday lunch work? If not, please >>>> suggest some alternate times. >>>> >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself >>>>only >>>> -------------- Randomly selected tag: --------------- >>>> You never finish a program, you just stop working on it. >> >> >> >>-- >>Randall Gellens >>Opinions are personal; facts are suspect; I speak for myself only >>-------------- Randomly selected tag: --------------- >>Howe's Law: >> Everyone has a scheme that will not work. > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- A bird in the hand is safer than one overhead. From nobody Fri Jul 10 08:12:57 2015 Return-Path: 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 688271A9240; Fri, 10 Jul 2015 08:12:57 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 Q-KQqpq8EqMg; Fri, 10 Jul 2015 08:12:56 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23951A923E; Fri, 10 Jul 2015 08:12:55 -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=1436541176; x=1468077176; h=message-id:in-reply-to:references:date:to:from:subject: cc; bh=vPaw4lTJiH0V0IiKSOBqnd38p4BHOZt8ct5JM2YR040=; b=pr+eF14j5Kl3fkjLuj0X/3WYd6sylHyFf4tQvEz+Uj5h0OlIQ1YO06sB 7XCtJXD11TWxfY/hxlLwQRltEb7JYNElGo9gmr643GCwRBrfC4qbL4VJ1 ViqKYZs4T6MQnacTYetpk93TdR6WOcNvoiCa8w5xmzRY8ZqMf5s5Mu3LU Q=; X-IronPort-AV: E=McAfee;i="5700,7163,7857"; a="92441827" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2015 08:12:56 -0700 X-IronPort-AV: E=Sophos;i="5.15,447,1432623600"; d="scan'208";a="958148955" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2015 08:12:55 -0700 Received: from Ironmsg03-R.qualcomm.com (ironmsg03-R.qualcomm.com [172.30.46.17]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t6AFCsgN030674; Fri, 10 Jul 2015 08:12:54 -0700 X-IronPort-AV: E=Sophos;i="5.15,447,1432623600"; d="scan'208";a="958148928" X-ojodefuego: yes Received: from unknown (HELO [99.111.97.136]) ([10.64.162.243]) by Ironmsg03-R.qualcomm.com with ESMTP; 10 Jul 2015 08:12:53 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Fri, 10 Jul 2015 08:08:59 -0700 To: "Rosen, Brian" , Bernard Aboba , Henning Schulzrinne From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: "slim@ietf.org" , ECRIT , Barry Leiba Subject: Re: [Ecrit] [Slim] Time in Prague to discuss SLIM real-time draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 15:12:57 -0000 Tuesday lunch is the email work. If the others can make Monday first afternoon session, let's do that. At 2:52 PM +0000 7/10/15, Brian Rosen wrote: > I'd like to go to clue, but I can skip it. Tuesday lunch would work. > > On 7/10/15, 10:51 AM, "Randall Gellens" wrote: > >>Would the first afternoon session (starts at 1:00) on Monday work? >> >>At 6:09 AM -0700 7/10/15, Bernard Aboba wrote: >> >>> I will be in Prague from Saturday through Friday. I cannot do >>> Monday lunch but other days are OK. >>> >>> >>> On Jul 9, 2015, at 7:26 PM, Henning Schulzrinne >>> <hgs@cs.columbia.edu> wrote: >>> >>>> I'm in Prague Sunday afternoon through Thursday morning, and >>>> fairly flexible. Thanks for organizing! >>>> >>>> On Wed, Jul 8, 2015 at 1:30 PM, Randall Gellens >>>> <randy@qti.qualcomm.com> wrote: >>>> >>>> I'd like to set a time to meet in Prague so that Bernard, Brian, >>>> myself, and anyone else interested can talk in depth about the >>>> SLIM real-time draft. Would Monday lunch work? If not, please >>>> suggest some alternate times. >>>> >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself >>>>only >>>> -------------- Randomly selected tag: --------------- >>>> You never finish a program, you just stop working on it. >> >> >> >>-- >>Randall Gellens >>Opinions are personal; facts are suspect; I speak for myself only >>-------------- Randomly selected tag: --------------- >>Howe's Law: >> Everyone has a scheme that will not work. > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Afternoon: That part of the day we spend worrying about how we wasted the morning. From nobody Fri Jul 10 08:27:08 2015 Return-Path: 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 607581AD49D for ; Fri, 10 Jul 2015 08:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.368 X-Spam-Level: X-Spam-Status: No, score=-0.368 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 j2FH1DOekerI for ; Fri, 10 Jul 2015 08:27:05 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4315F1A9248 for ; Fri, 10 Jul 2015 08:27:05 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6AFNPg8006006 for ; Fri, 10 Jul 2015 11:27:05 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1vj7jk8n6r-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 10 Jul 2015 11:27:04 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.249]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Fri, 10 Jul 2015 11:27:02 -0400 From: "Rosen, Brian" To: ECRIT mailing list Thread-Topic: lost-planned-changes Thread-Index: AQHQuyTe3OHCK8hzekefEa0dtFYxcQ== Date: Fri, 10 Jul 2015 15:27:01 +0000 Message-ID: <6F2C97E4-B54A-4153-92FD-B08469F2AC2D@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.32] Content-Type: text/plain; charset="utf-8" Content-ID: <0B0D64226F775E46B240A1032BE00304@neustar.biz> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-10_07:2015-07-10,2015-07-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [Ecrit] lost-planned-changes X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 15:27:06 -0000 VGhlIHJlYXNvbiB0aGVyZSBpcyByZW5ld2VkIHN1cHBvcnQgZm9yIGxvc3QtcGxhbm5lZC1jaGFu Z2VzIGlzIHRoYXQgdGhlIE5FTkEgZ3V5cyBhcmUgZ2V0dGluZyBtb3JlIGFuZCBtb3JlIGV4cGVy aWVuY2UgZGVwbG95aW5nIExvU1QgYW5kIHJlYWxpemUgdGhhdCB0aGUgbnVtYmVyIG9mIHRyYW5z YWN0aW9ucyBkb2luZyBwZXJpb2QgcmVmcmVzaCBpcyBtdWNoLCBtdWNoIG1vcmUgdGhhbiBlbWVy Z2VuY3kgY2FsbCB0cmFuc2FjdGlvbnMsIGFuZCB0aGF0IHNldHRpbmcgdGhlIHBlcmlvZCB0byB3 aGF0IHlvdSB3b3VsZCBuZWVkIHRvIGtlZXAgdXAgd2l0aCByYXBpZGx5IGdyb3dpbmcgY29tbXVu aXRpZXMgbWFrZXMgdGhlIHRyYWZmaWMgcmlkaWN1bG91cy4gIFdlIG5lZWQgYSBtdWNoIGJldHRl ciB3YXkgdG8ga25vdyB0aGF0IGEgbG9jYXRpb24gdGhhdCB1c2VkIHRvIGJlIHZhbGlkIGlzIG5v IGxvbmdlciB2YWxpZCAob3Igd2lsbCBzb29uIGJlIGludmFsaWQpLiAgU29tZW9uZSBhc2tlZCB3 aGF0IHdhcyBoYXBwZW5pbmcgdG8gdGhlIGRyYWZ0LCBJIHRvbGQgdGhlbSB0aGV5IEkgaGFkIGlu c3VmZmljaWVudCBpbnRlcmVzdCB0byBwcm9ncmVzcywgYW5kIHRoZXkgcmVzcG9uZGVkIGJ5IHJl YWRpbmcgdGhlIGRyYWZ0ICghKSBhbmQgY2hpbWluZyBpbi4gICBUaGUgcGVvcGxlIHRoYXQgaGF2 ZSBzZW50IG1haWwgYXJlIGFjdGl2ZWx5IGRlcGxveWluZyBMb1NULiANCg0KVGhlIGRyYWZ0IGlz IGV4cGlyZWQsIGFuZCBpdOKAmXMgc2hvcnQuICBJ4oCZbGwgcmVmcmVzaCBpdCB3aGVuIHRoZSB3 aW5kb3cgb3BlbnMgYnV0IEnigJlkIGxpa2UgdG8gZ2V0IGl0IGFkb3B0ZWQgYW5kIG91dCB0aGUg ZG9vciBzb29uLg0KDQpUaGVyZSB3aWxsIGFsc28gYmUgYSBjb3VwbGUgb2YgZHJhZnRzIGNvbWlu ZyB0aGF0IGFkZHJlc3Mgb3RoZXIgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMgZGlzY292ZXJlZCBp biBORU5BIOKAnElDReKAnSBldmVudHMuDQoNCkRlcGxveW1lbnQgZXhwZXJpZW5jZSBpcyBnb29k ISAgDQoNCkJyaWFu From nobody Fri Jul 10 09:59:36 2015 Return-Path: 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 704221B2A58 for ; Fri, 10 Jul 2015 09:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3] 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 VsT4LoR5J1eY for ; Fri, 10 Jul 2015 09:59:35 -0700 (PDT) Received: from p01c11o149.mxlogic.net (p01c11o149.mxlogic.net [208.65.144.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78041B2A5B for ; Fri, 10 Jul 2015 09:59:34 -0700 (PDT) Received: from unknown [64.58.50.3] (EHLO smtp1.intrado.com) by p01c11o149.mxlogic.net(mxl_mta-8.4.0-1) with ESMTP id 6f9ff955.2b3efcf8d940.390313.00-548.1100281.p01c11o149.mxlogic.net (envelope-from ); Fri, 10 Jul 2015 10:59:34 -0600 (MDT) X-MXL-Hash: 559ff9f6229c6c01-dc66ee2b26ca4efb7947eb364d143dafaea64161 Received: from unknown [64.58.50.3] (EHLO smtp1.intrado.com) by p01c11o149.mxlogic.net(mxl_mta-8.4.0-1) over TLS secured channel with ESMTP id 3f9ff955.0.390245.00-350.1100073.p01c11o149.mxlogic.net (envelope-from ); Fri, 10 Jul 2015 10:59:33 -0600 (MDT) X-MXL-Hash: 559ff9f5683adacc-edc2a008cf311481cb087c78bd47a1a1dede91c4 Received: from lmv08-bh01.intrado.com (10.100.104.6) by smtp1.intrado.com (10.100.70.11) with Microsoft SMTP Server id 14.2.347.0; Fri, 10 Jul 2015 10:59:30 -0600 Received: from lmv08-mx02.corp.intrado.pri (10.100.4.23) by mail.intrado.com (192.168.104.4) with Microsoft SMTP Server id 14.2.347.0; Fri, 10 Jul 2015 10:59:29 -0600 Received: from LMV08-MX04.corp.intrado.pri ([::1]) by lmv08-mx02.corp.intrado.pri ([::1]) with mapi; Fri, 10 Jul 2015 10:59:30 -0600 From: "Sherry, Robert" To: "Rosen, Brian" , ECRIT mailing list Date: Fri, 10 Jul 2015 10:59:28 -0600 Thread-Topic: lost-planned-changes Thread-Index: AQHQuyTe3OHCK8hzekefEa0dtFYxcZ3U54mw Message-ID: References: <6F2C97E4-B54A-4153-92FD-B08469F2AC2D@neustar.biz> In-Reply-To: <6F2C97E4-B54A-4153-92FD-B08469F2AC2D@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.000.1202-21668.005 X-TM-AS-Result: No--8.275600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.1 cv=efkpft0H c=1 sm=1 tr=0 a=fK0x7wWexdliSyovM0KqDA==] X-AnalysisOut: [:117 a=fK0x7wWexdliSyovM0KqDA==:17 a=eHlaXHVRAAAA:8 a=YlVT] X-AnalysisOut: [AMxIAAAA:8 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=zOBTXjUuO] X-AnalysisOut: [1YA:10 a=48vgC7mUAAAA:8 a=GKK3kuHTRoX9-8aaiXUA:9 a=Hub497C] X-AnalysisOut: [6Zuly7HKS:21 a=AOcEcEto5_bqEfaq:21 a=QEXdDO2ut3YA:10 a=NG9] X-AnalysisOut: [FLc5EiJEA:10 a=qT2Vnc1ob_oA:10 a=eN-VsI6IX7MA:10 a=iEWpRP5] X-AnalysisOut: [WgT0A:10 a=F0plUGpYEAoA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2015071009); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [64.58.50.3] Archived-At: Subject: Re: [Ecrit] lost-planned-changes X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 16:59:36 -0000 DQpKdXN0IHRvIGdpdmUgYSByZWFsIGxpZmUgZXhhbXBsZS4NCkludHJhZG8gcHJvdmlkZXMgYSBu YXRpb253aWRlIHJvdXRpbmcgc2VydmljZSBmb3IgVm9JUCBwcm92aWRlcnMuDQpDdXJyZW50bHkg d2UgZ2V0IGEgTVNBRyBmcm9tIHRoZSA5MTEgYXV0aG9yaXR5IGFuZCBoYXZlIGEgdmFsaWRhdGlv biBkYXRhYmFzZSBzaW1pbGFyIHRvIHRoZSB3YXkgRTktMS0xIGlzIGRvbmUuDQpWb0lQIHByb3Zp ZGVycyBzZW5kIHVzIHRoZWlyIGFkZHJlc3NlcyBhbmQgd2UgdmFsaWRhdGUgdGhlbSBhbmQgZW50 ZXIgdGhlIHJlc3VsdHMgaW4gb3VyIFZQQy4NCg0KQXMgd2UgbW92ZSB0b3dhcmQgTkc5LTEtMSB3 ZSBhcmUgYmVpbmcgYXNrZWQgdG8gdmFsaWRhdGUgYWdhaW5zdCBMVkZzLg0KQXMgeW91IGNhbiBp bWFnaW5lIHRoZXNlIFZvSVAgcHJvdmlkZXJzIGhhdmUgbWlsbGlvbnMgb2YgY3VzdG9tZXJzIChh ZGRyZXNzZXMpIGFuZCBpbiB0aGUgRTktMS0xIHNjZW5hcmlvIGFkZHJlc3NlcyB3ZXJlIGF1dG9t YXRpY2FsbHkgdXBkYXRlZCB3aGVuIHRoZSBNU0FHIGNoYW5nZWQuDQpUaGUgcHJvYmFiaWxpdHkg b2Ygc3RhbGUgYWRkcmVzc2VzIHBlciBwcm92aWRlciBpbmNyZWFzZXMgd2l0aCBzY2FsZS4NCklu IHRoZSBjdXJyZW50IHNjZW5hcmlvIHdlIHdvdWxkIGhhdmUgdG8gYmUgc2VuZGluZyAxMHMgb2Yg bWlsbGlvbiByZXZhbGlkYXRpb25zIG1vbnRobHkgdG8gaGVscCBhbGxldmlhdGUgdGhlIHBvc3Np YmlsaXR5IG9mIHN0YWxlIGxvY2F0aW9ucy4NCg0KVGhlIGFiaWxpdHkgdG8gbm90aWZ5IG91ciBz eXN0ZW1zIHRoYXQgYSB2YWxpZGF0aW9uIGhhcyBjaGFuZ2VkIHdvdWxkIG1pbmltaXplIHRoZSBu dW1iZXIgb2YgcmV2YWxpZGF0aW9uIHJlcXVlc3RzIHRoYXQgd2Ugd291bGQgaGF2ZSB0byBwZXJm b3JtLg0KDQpPdGhlciBwb3RlbnRpYWwgaW1wcm92ZW1lbnRzIHRoYXQgd291bGQgaGVscC4NCjEp IEEgYmF0Y2ggcHJvY2Vzcw0KSW4gRTktMS0xIHRoZSBTZXJ2aWNlIE9yZGVyIHN5c3RlbSBwcm92 aWRlcyBiYXRjaGVzIG9mIGFkZHJlc3NlcyB0byB0aGUgdmFsaWRhdGlvbiBkYXRhYmFzZSBpbiBh IHNpbmdsZSBxdWVyeS4NClRoZSByZXNwb25zZSBjb250YWlucyB0aGUgcmVzdWx0IG9mIHRoZSB2 YWxpZGF0aW9uIGZvciBlYWNoIGFkZHJlc3MuDQpUaGlzIHByb3ZpZGVzIGVmZmljaWVuY2llcyBp biBuZXR3b3JrIGNhcGFjaXR5Lg0KDQoyKSBJbmRpY2F0aW9uIG9mIGFsdGVybmF0aXZlcw0KQ3Vy cmVudGx5IG91ciBEYXRhIEludGVncml0eSBVbml0IChESVUpIHN0YWZmIG1hbmFnZSBhbnkgZmFs bCBvdXRzIG9mIHZhbGlkYXRpb24gZmFpbHVyZS4NCkFzIHdlIG1vdmUgdG8gTkc5LTEtMSBpdCB3 b3VsZCBiZSB1c2VmdWwgZm9yIHRoZSBMVkYgdG8gcmV0dXJuIHRoZSAiY29ycmVjdCIgYWRkcmVz cyBlbGVtZW50IG9yIGEgc3VnZ2VzdGlvbiBvZiBhZGRyZXNzIGVsZW1lbnRzLiANCg0KDQpCb2Ig U2hlcnJ5LCBFTlAgDQpJbnRyYWRvIEluYy4NCjMwMzAgV2FycmVudmlsbGUgUmQsIDR0aCBGbG9v cg0KTGlzbGUsIElMIDYwNTMyDQpkaXJlY3Q6IDYzMC0zMDAtMjgzOMKgwqAgbW9iaWxlOiA2MzAt ODgwLTM3MDQNCmZheDogNzIwLTQ5NC02NjAwwqAgZW1haWw6IFJvYmVydC5TaGVycnlAaW50cmFk by5jb20NCsKgDQpJbnRyYWRvDQp3d3cuaW50cmFkby5jb20gDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBFY3JpdCBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBSb3NlbiwgQnJpYW4NClNlbnQ6IEZyaWRheSwgSnVseSAxMCwgMjAxNSAxMDoy NyBBTQ0KVG86IEVDUklUIG1haWxpbmcgbGlzdA0KU3ViamVjdDogW0Vjcml0XSBsb3N0LXBsYW5u ZWQtY2hhbmdlcw0KDQpUaGUgcmVhc29uIHRoZXJlIGlzIHJlbmV3ZWQgc3VwcG9ydCBmb3IgbG9z dC1wbGFubmVkLWNoYW5nZXMgaXMgdGhhdCB0aGUgTkVOQSBndXlzIGFyZSBnZXR0aW5nIG1vcmUg YW5kIG1vcmUgZXhwZXJpZW5jZSBkZXBsb3lpbmcgTG9TVCBhbmQgcmVhbGl6ZSB0aGF0IHRoZSBu dW1iZXIgb2YgdHJhbnNhY3Rpb25zIGRvaW5nIHBlcmlvZCByZWZyZXNoIGlzIG11Y2gsIG11Y2gg bW9yZSB0aGFuIGVtZXJnZW5jeSBjYWxsIHRyYW5zYWN0aW9ucywgYW5kIHRoYXQgc2V0dGluZyB0 aGUgcGVyaW9kIHRvIHdoYXQgeW91IHdvdWxkIG5lZWQgdG8ga2VlcCB1cCB3aXRoIHJhcGlkbHkg Z3Jvd2luZyBjb21tdW5pdGllcyBtYWtlcyB0aGUgdHJhZmZpYyByaWRpY3Vsb3VzLiAgV2UgbmVl ZCBhIG11Y2ggYmV0dGVyIHdheSB0byBrbm93IHRoYXQgYSBsb2NhdGlvbiB0aGF0IHVzZWQgdG8g YmUgdmFsaWQgaXMgbm8gbG9uZ2VyIHZhbGlkIChvciB3aWxsIHNvb24gYmUgaW52YWxpZCkuICBT b21lb25lIGFza2VkIHdoYXQgd2FzIGhhcHBlbmluZyB0byB0aGUgZHJhZnQsIEkgdG9sZCB0aGVt IHRoZXkgSSBoYWQgaW5zdWZmaWNpZW50IGludGVyZXN0IHRvIHByb2dyZXNzLCBhbmQgdGhleSBy ZXNwb25kZWQgYnkgcmVhZGluZyB0aGUgZHJhZnQgKCEpIGFuZCBjaGltaW5nIGluLiAgIFRoZSBw ZW9wbGUgdGhhdCBoYXZlIHNlbnQgbWFpbCBhcmUgYWN0aXZlbHkgZGVwbG95aW5nIExvU1QuIA0K DQpUaGUgZHJhZnQgaXMgZXhwaXJlZCwgYW5kIGl04oCZcyBzaG9ydC4gIEnigJlsbCByZWZyZXNo IGl0IHdoZW4gdGhlIHdpbmRvdyBvcGVucyBidXQgSeKAmWQgbGlrZSB0byBnZXQgaXQgYWRvcHRl ZCBhbmQgb3V0IHRoZSBkb29yIHNvb24uDQoNClRoZXJlIHdpbGwgYWxzbyBiZSBhIGNvdXBsZSBv ZiBkcmFmdHMgY29taW5nIHRoYXQgYWRkcmVzcyBvdGhlciBpbnRlcm9wZXJhYmlsaXR5IGlzc3Vl cyBkaXNjb3ZlcmVkIGluIE5FTkEg4oCcSUNF4oCdIGV2ZW50cy4NCg0KRGVwbG95bWVudCBleHBl cmllbmNlIGlzIGdvb2QhICANCg0KQnJpYW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpFY3JpdCBtYWlsaW5nIGxpc3QNCkVjcml0QGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo= From nobody Fri Jul 10 10:01:04 2015 Return-Path: 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 9FAC91B2A44 for ; Fri, 10 Jul 2015 10:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 2WnRk8F93Vmc for ; Fri, 10 Jul 2015 10:01:01 -0700 (PDT) Received: from bin-vsp-out-05.atm.binero.net (vsp-authed01.binero.net [195.74.38.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435AB1A0277 for ; Fri, 10 Jul 2015 10:01:00 -0700 (PDT) X-Halon-ID: 427fc547-2725-11e5-8d76-005056916f53 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.42] (unknown [87.96.160.92]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Fri, 10 Jul 2015 19:01:08 +0200 (CEST) Message-ID: <559FFA45.1010304@omnitor.se> Date: Fri, 10 Jul 2015 19:00:53 +0200 From: =?UTF-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Laura Liess References: <6EB1BAFC-49FC-4D1F-92A2-E01C931FE92B@cisco.com> <8756CB1D-6CC2-405A-86E3-E89BDB607E81@gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01EF730DD21E@HE113667.emea1.cds.t-internal.com> <276B7588-3377-4900-9125-4F7729F4E530@cooperw.in> <55950507.3010306@omnitor.se> <949EF20990823C4C85C18D59AA11AD8B69738934@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010506030905040900030904" Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-held-routing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 17:01:03 -0000 This is a multi-part message in MIME format. --------------010506030905040900030904 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Laura Liess skrev den 2015-07-03 09:13: > Gunnar, > > Keith is right. The draft is intended to enable the LIS to provide the > SIP-URI of an Emergency Calling Routing Proxy (ESRP) trusted by the > LIS, which is able to dereference the LbyR sent in the emergency call > and then route the emergency call to the correct. PSAP. We can not > expect the LIS of every small access network provider to have deep > knowledge about the PSAP-infrastructure, we expect the ESRP to have it > or to be able to get it. The ESRP is also able to analyse the > emergency call, find out, e.g., if the caller would prefer text to > audio and route it to the apropriate PSAP. I think in some countries > (UK ?) they have one central PSAP which gets all emergency calls and > then route them to the appropriate local PSAP. (This why we have > ESRP/PSAP and "routing to the appropriate PSAP in the draft.) > There is no need to consider other factors such as time of day, caller > media requests, language preference, and call load to be considered > at then interface between the Softswithch and the LIS, these factors > have to be considered by the ESRP when it chooses the final > destination (PSAP) for the emergency call. Right. I find held-routing to be appropriate for its task. Good. /Gunnar > > Thank you > Laura > > 2015-07-02 15:59 GMT+02:00 DRAGE, Keith (Keith) > >: > > In regard to your question in 2). > > Any routeing decisions are made in the ESRP as indicated in figure > 1 and 2. > > As far as I can tell the draft is silent on what the ESRP does as > far as routeing is concerned, except to make the statement: > > The terms LIS, ESRP, VSP and PSAP are used as defined in [RFC6443]. > > Which encompasses exactly the reference you have made. > > The draft is essentially about getting a location to the entity > making the routeing decision, not about how the routeing decision > is made. > > Regards > > Keith > > > -----Original Message----- > > From: Ecrit [mailto:ecrit-bounces@ietf.org > ] On Behalf Of > > Gunnar Hellström > > Sent: 02 July 2015 10:32 > > To: ecrit@ietf.org > > Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-held-routing > > > > I have seen one minor typo and have one question: > > > > 1. Typo: > > In 3, second line under figure 1, starts: > > "initiates and emergency" > > should be: > > "initiates an emergency" > > > > 2. Question: > > > > The draft only talks about routing by location information. > > Is there no need to consider other data involved in the > > routing decisions, as e.g. stated in this paragraph in RFC > > 6443, section 6: > > > > " Routing to the most appropriate PSAP is always based on > > the location > > of the caller, despite the fact that some emergency calls > > are placed > > on behalf of someone else, and the location of the incident is > > sometimes not the location of the caller. In some cases, > > there are > > other factors that enter into the choice of the PSAP that > gets the > > call, such as time of day, caller media requests, language > > preference, and call load. However, location of the caller > is the > > primary input to the routing decision." > > > > Regards > > > > If the answer on this question does not cause any major > > rethinking, I support publishing. > > > > Gunnar > > > > > > -- > > ----------------------------------------- > > Gunnar Hellström > > Omnitor > > gunnar.hellstrom@omnitor.se > > +46 708 204 288 > > > > > > > > Alissa Cooper skrev den 2015-07-02 00:59: > > > The WGLC already came and went. > > > > > > I'd like to know if folks (other than the authors) have > > reviewed the draft and support its publication. > > > > > > Thanks, > > > Alissa > > > > > > On Jun 21, 2015, at 11:32 PM, R.Jesske@telekom.de > wrote: > > > > > >> I support to proceed this draft to WGLC. > > >> > > >> Best Regards > > >> > > >> Roland > > >> > > >>> On 27 May 2015, at 10:05 pm, Marc Linsner (mlinsner) > > > wrote: > > >>> > > >>> All, > > >>> > > >>> This marks the start of working group last call on this > > draft. Please review and send comments to the list by COB, > > Wednesday June 10th, 2015. > > >>> > > >>> https://tools.ietf.org/html/draft-ietf-ecrit-held-routing-02 > > >>> > > >>> Thanks, > > >>> > > >>> Marc & Roger > > >>> > > >>> > > >>> _______________________________________________ > > >>> Ecrit mailing list > > >>> Ecrit@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/ecrit > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ecrit > > >> > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > -- > > ----------------------------------------- > > Gunnar Hellström > > Omnitor > > gunnar.hellstrom@omnitor.se > > +46 708 204 288 > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------010506030905040900030904 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Laura Liess skrev den 2015-07-03 09:13:
Gunnar,

Keith is right. The draft is intended to enable the LIS to provide the SIP-URI of an Emergency Calling Routing Proxy (ESRP) trusted by the LIS, which is able to dereference the LbyR sent in the emergency call and then route the emergency call to the correct. PSAP. We can not expect the LIS of every small access network provider to have deep knowledge about the PSAP-infrastructure, we expect the ESRP to have it or to be able to get it.  The  ESRP is also able to analyse the emergency call, find out, e.g.,  if the caller would prefer text to audio and route it to the apropriate PSAP.  I think in some countries (UK ?)  they have one central PSAP which gets all emergency calls and then route them to the appropriate local PSAP. (This why we have ESRP/PSAP and "routing to the appropriate PSAP in the draft.)
There is no need to consider other factors such as time of day, caller media requests, language  preference, and call load to be considered at then interface between the Softswithch and the LIS, these factors have to be considered by the ESRP when it chooses the final destination (PSAP) for the emergency call.   
Right. I find held-routing to be appropriate for its task.
Good.

/Gunnar

Thank you
Laura

2015-07-02 15:59 GMT+02:00 DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com>:
In regard to your question in 2).

Any routeing decisions are made in the ESRP as indicated in figure 1 and 2.

As far as I can tell the draft is silent on what the ESRP does as far as routeing is concerned, except to make the statement:

   The terms LIS, ESRP, VSP and PSAP are used as defined in [RFC6443].

Which encompasses exactly the reference you have made.

The draft is essentially about getting a location to the entity making the routeing decision, not about how the routeing decision is made.

Regards

Keith

> -----Original Message-----
> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of
> Gunnar Hellström
> Sent: 02 July 2015 10:32
> To: ecrit@ietf.org
> Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-held-routing
>
> I have seen one minor typo and have one question:
>
> 1. Typo:
> In 3, second line under figure 1, starts:
> "initiates and emergency"
> should be:
> "initiates an emergency"
>
> 2. Question:
>
> The draft only talks about routing by location information.
> Is there no need to consider other data involved in the
> routing decisions, as e.g. stated in this paragraph in RFC
> 6443, section 6:
>
> "  Routing to the most appropriate PSAP is always based on
> the location
>     of the caller, despite the fact that some emergency calls
> are placed
>     on behalf of someone else, and the location of the incident is
>     sometimes not the location of the caller.  In some cases,
> there are
>     other factors that enter into the choice of the PSAP that gets the
>     call, such as time of day, caller media requests, language
>     preference, and call load.  However, location of the caller is the
>     primary input to the routing decision."
>
> Regards
>
> If the answer on this question does not cause any major
> rethinking, I support publishing.
>
> Gunnar
>
>
> --
> -----------------------------------------
> Gunnar Hellström
> Omnitor
> gunnar.hellstrom@omnitor.se
> +46 708 204 288
>
>
>
> Alissa Cooper skrev den 2015-07-02 00:59:
> > The WGLC already came and went.
> >
> > I'd like to know if folks (other than the authors) have
> reviewed the draft and support its publication.
> >
> > Thanks,
> > Alissa
> >
> > On Jun 21, 2015, at 11:32 PM, R.Jesske@telekom.de wrote:
> >
> >> I support to proceed this draft to WGLC.
> >>
> >> Best Regards
> >>
> >> Roland
> >>
> >>> On 27 May 2015, at 10:05 pm, Marc Linsner (mlinsner)
> <mlinsner@cisco.com> wrote:
> >>>
> >>> All,
> >>>
> >>> This marks the start of working group last call on this
> draft.  Please review and send comments to the list by COB,
> Wednesday June 10th, 2015.
> >>>
> >>> https://tools.ietf.org/html/draft-ietf-ecrit-held-routing-02
> >>>
> >>> Thanks,
> >>>
> >>> Marc & Roger
> >>>
> >>>
> >>> _______________________________________________
> >>> Ecrit mailing list
> >>> Ecrit@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/ecrit
> >> _______________________________________________
> >> Ecrit mailing list
> >> Ecrit@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>
> >> _______________________________________________
> >> Ecrit mailing list
> >> Ecrit@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ecrit
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit@ietf.org
> > https://www.ietf.org/mailman/listinfo/ecrit
>
> --
> -----------------------------------------
> Gunnar Hellström
> Omnitor
> gunnar.hellstrom@omnitor.se
> +46 708 204 288
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------010506030905040900030904-- From nobody Fri Jul 10 10:12:11 2015 Return-Path: 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 AA5761B2A6B for ; Fri, 10 Jul 2015 10:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 Gi1ajQ0d7Mmr for ; Fri, 10 Jul 2015 10:12:09 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91301B2A6A for ; Fri, 10 Jul 2015 10:12:08 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6AH4H4N003670; Fri, 10 Jul 2015 13:12:08 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1vjggbr5b5-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 10 Jul 2015 13:12:08 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.249]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Fri, 10 Jul 2015 13:12:08 -0400 From: "Rosen, Brian" To: "Sherry, Robert" Thread-Topic: [Ecrit] lost-planned-changes Thread-Index: AQHQuyTeCviz2sLtrkGesIVNN7TrMZ3VMFQAgAADh4A= Date: Fri, 10 Jul 2015 17:12:07 +0000 Message-ID: <3549E808-24C0-496D-8A19-DA2F3FC92E3E@neustar.biz> References: <6F2C97E4-B54A-4153-92FD-B08469F2AC2D@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.32] Content-Type: text/plain; charset="utf-8" Content-ID: <705856FF7F89A24EA46D662D7775D6AF@neustar.biz> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-10_07:2015-07-10,2015-07-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: ECRIT mailing list Subject: Re: [Ecrit] lost-planned-changes X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 17:12:10 -0000 Tm90ZSB0aGF0IC1jb21wbGV0ZWQtbG9jYXRpb24gcHJvdmlkZXMgdGhlIHN1Z2dlc3RlZCBjb3Jy ZWN0IGFkZHJlc3MgZmVhdHVyZSBCb2IgYXNrZWQgZm9yLg0KDQpXZSBjZXJ0YWlubHkgY291bGQg Y29uc2lkZXIgc3RhbmRhcmRpemVkIGEgYmF0Y2ggc3lzdGVtLCB3aGljaCBwcmVzdW1hYmx5IHdv dWxkIGJlIGEgZmlsZSB1cGxvYWQgYW5kIGRvd25sb2FkLiAgSWYgd2UganVzdCBwdXQgdGhlIGV4 aXN0aW5nIG1hcHBpbmcgcmVxdWVzdCBhbmQgcmVzcG9uc2UgYXMgdGhleSBhcmUgY3VycmVudGx5 IGRlZmluZWQgaW4gdGhlIGZpbGVzLCBJIHdvdWxkIG5vdCBleHBlY3QgYW55IHN1YnN0YW50aWFs IGluY3JlYXNlIGluIG5ldHdvcmsgZWZmaWNpZW5jeS4gIElmIHdlIGRpZCBzb21ldGhpbmcgcmFk aWNhbGx5IGRpZmZlcmVudCAtIGJhc2ljYWxseSByZXBlYXRpbmcgdGhlIGxvY2F0aW9uIGluZm9y bWF0aW9uIGVsZW1lbnQgbXVsdGlwbGUgdGltZXMgYW5kIHRoZSBzYW1lIHdpdGggdGhlIHJlc3Bv bnNlIHZhbGlkaXR5IGNoZWNrIHJlc3BvbnNlLCB0aGVuIHlvdSBtaWdodCBnZXQgc29tZSBtZWFu aW5nZnVsIGltcHJvdmVtZW50LCBidXQgaXQgZG9lcyBzZWVtcyBsaWtlIGl0IHdvdWxkbuKAmXQg YmUgYWxsIHRoYXQgbXVjaC4gICAgSGF2ZSB0byB0cnkgaXQgYW5kIHNlZSB3aGF0IGl0IG1pZ2h0 IGRvLg0KDQpCcmlhbg0KDQo+IA0KPiBPbiBKdWwgMTAsIDIwMTUsIGF0IDEyOjU5IFBNLCBTaGVy cnksIFJvYmVydCA8Um9iZXJ0LlNoZXJyeUBpbnRyYWRvLmNvbT4gd3JvdGU6DQo+IA0KPiANCj4g SnVzdCB0byBnaXZlIGEgcmVhbCBsaWZlIGV4YW1wbGUuDQo+IEludHJhZG8gcHJvdmlkZXMgYSBu YXRpb253aWRlIHJvdXRpbmcgc2VydmljZSBmb3IgVm9JUCBwcm92aWRlcnMuDQo+IEN1cnJlbnRs eSB3ZSBnZXQgYSBNU0FHIGZyb20gdGhlIDkxMSBhdXRob3JpdHkgYW5kIGhhdmUgYSB2YWxpZGF0 aW9uIGRhdGFiYXNlIHNpbWlsYXIgdG8gdGhlIHdheSBFOS0xLTEgaXMgZG9uZS4NCj4gVm9JUCBw cm92aWRlcnMgc2VuZCB1cyB0aGVpciBhZGRyZXNzZXMgYW5kIHdlIHZhbGlkYXRlIHRoZW0gYW5k IGVudGVyIHRoZSByZXN1bHRzIGluIG91ciBWUEMuDQo+IA0KPiBBcyB3ZSBtb3ZlIHRvd2FyZCBO RzktMS0xIHdlIGFyZSBiZWluZyBhc2tlZCB0byB2YWxpZGF0ZSBhZ2FpbnN0IExWRnMuDQo+IEFz IHlvdSBjYW4gaW1hZ2luZSB0aGVzZSBWb0lQIHByb3ZpZGVycyBoYXZlIG1pbGxpb25zIG9mIGN1 c3RvbWVycyAoYWRkcmVzc2VzKSBhbmQgaW4gdGhlIEU5LTEtMSBzY2VuYXJpbyBhZGRyZXNzZXMg d2VyZSBhdXRvbWF0aWNhbGx5IHVwZGF0ZWQgd2hlbiB0aGUgTVNBRyBjaGFuZ2VkLg0KPiBUaGUg cHJvYmFiaWxpdHkgb2Ygc3RhbGUgYWRkcmVzc2VzIHBlciBwcm92aWRlciBpbmNyZWFzZXMgd2l0 aCBzY2FsZS4NCj4gSW4gdGhlIGN1cnJlbnQgc2NlbmFyaW8gd2Ugd291bGQgaGF2ZSB0byBiZSBz ZW5kaW5nIDEwcyBvZiBtaWxsaW9uIHJldmFsaWRhdGlvbnMgbW9udGhseSB0byBoZWxwIGFsbGV2 aWF0ZSB0aGUgcG9zc2liaWxpdHkgb2Ygc3RhbGUgbG9jYXRpb25zLg0KPiANCj4gVGhlIGFiaWxp dHkgdG8gbm90aWZ5IG91ciBzeXN0ZW1zIHRoYXQgYSB2YWxpZGF0aW9uIGhhcyBjaGFuZ2VkIHdv dWxkIG1pbmltaXplIHRoZSBudW1iZXIgb2YgcmV2YWxpZGF0aW9uIHJlcXVlc3RzIHRoYXQgd2Ug d291bGQgaGF2ZSB0byBwZXJmb3JtLg0KPiANCj4gT3RoZXIgcG90ZW50aWFsIGltcHJvdmVtZW50 cyB0aGF0IHdvdWxkIGhlbHAuDQo+IDEpIEEgYmF0Y2ggcHJvY2Vzcw0KPiBJbiBFOS0xLTEgdGhl IFNlcnZpY2UgT3JkZXIgc3lzdGVtIHByb3ZpZGVzIGJhdGNoZXMgb2YgYWRkcmVzc2VzIHRvIHRo ZSB2YWxpZGF0aW9uIGRhdGFiYXNlIGluIGEgc2luZ2xlIHF1ZXJ5Lg0KPiBUaGUgcmVzcG9uc2Ug Y29udGFpbnMgdGhlIHJlc3VsdCBvZiB0aGUgdmFsaWRhdGlvbiBmb3IgZWFjaCBhZGRyZXNzLg0K PiBUaGlzIHByb3ZpZGVzIGVmZmljaWVuY2llcyBpbiBuZXR3b3JrIGNhcGFjaXR5Lg0KPiANCj4g MikgSW5kaWNhdGlvbiBvZiBhbHRlcm5hdGl2ZXMNCj4gQ3VycmVudGx5IG91ciBEYXRhIEludGVn cml0eSBVbml0IChESVUpIHN0YWZmIG1hbmFnZSBhbnkgZmFsbCBvdXRzIG9mIHZhbGlkYXRpb24g ZmFpbHVyZS4NCj4gQXMgd2UgbW92ZSB0byBORzktMS0xIGl0IHdvdWxkIGJlIHVzZWZ1bCBmb3Ig dGhlIExWRiB0byByZXR1cm4gdGhlICJjb3JyZWN0IiBhZGRyZXNzIGVsZW1lbnQgb3IgYSBzdWdn ZXN0aW9uIG9mIGFkZHJlc3MgZWxlbWVudHMuIA0KPiANCj4gDQo+IEJvYiBTaGVycnksIEVOUCAN Cj4gSW50cmFkbyBJbmMuDQo+IDMwMzAgV2FycmVudmlsbGUgUmQsIDR0aCBGbG9vcg0KPiBMaXNs ZSwgSUwgNjA1MzINCj4gZGlyZWN0OiA2MzAtMzAwLTI4MzggICBtb2JpbGU6IDYzMC04ODAtMzcw NA0KPiBmYXg6IDcyMC00OTQtNjYwMCAgZW1haWw6IFJvYmVydC5TaGVycnlAaW50cmFkby5jb20N Cj4gIA0KPiBJbnRyYWRvDQo+IHd3dy5pbnRyYWRvLmNvbSANCj4gDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IEVjcml0IFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFJvc2VuLCBCcmlhbg0KPiBTZW50OiBGcmlkYXksIEp1bHkgMTAsIDIw MTUgMTA6MjcgQU0NCj4gVG86IEVDUklUIG1haWxpbmcgbGlzdA0KPiBTdWJqZWN0OiBbRWNyaXRd IGxvc3QtcGxhbm5lZC1jaGFuZ2VzDQo+IA0KPiBUaGUgcmVhc29uIHRoZXJlIGlzIHJlbmV3ZWQg c3VwcG9ydCBmb3IgbG9zdC1wbGFubmVkLWNoYW5nZXMgaXMgdGhhdCB0aGUgTkVOQSBndXlzIGFy ZSBnZXR0aW5nIG1vcmUgYW5kIG1vcmUgZXhwZXJpZW5jZSBkZXBsb3lpbmcgTG9TVCBhbmQgcmVh bGl6ZSB0aGF0IHRoZSBudW1iZXIgb2YgdHJhbnNhY3Rpb25zIGRvaW5nIHBlcmlvZCByZWZyZXNo IGlzIG11Y2gsIG11Y2ggbW9yZSB0aGFuIGVtZXJnZW5jeSBjYWxsIHRyYW5zYWN0aW9ucywgYW5k IHRoYXQgc2V0dGluZyB0aGUgcGVyaW9kIHRvIHdoYXQgeW91IHdvdWxkIG5lZWQgdG8ga2VlcCB1 cCB3aXRoIHJhcGlkbHkgZ3Jvd2luZyBjb21tdW5pdGllcyBtYWtlcyB0aGUgdHJhZmZpYyByaWRp Y3Vsb3VzLiAgV2UgbmVlZCBhIG11Y2ggYmV0dGVyIHdheSB0byBrbm93IHRoYXQgYSBsb2NhdGlv biB0aGF0IHVzZWQgdG8gYmUgdmFsaWQgaXMgbm8gbG9uZ2VyIHZhbGlkIChvciB3aWxsIHNvb24g YmUgaW52YWxpZCkuICBTb21lb25lIGFza2VkIHdoYXQgd2FzIGhhcHBlbmluZyB0byB0aGUgZHJh ZnQsIEkgdG9sZCB0aGVtIHRoZXkgSSBoYWQgaW5zdWZmaWNpZW50IGludGVyZXN0IHRvIHByb2dy ZXNzLCBhbmQgdGhleSByZXNwb25kZWQgYnkgcmVhZGluZyB0aGUgZHJhZnQgKCEpIGFuZCBjaGlt aW5nIGluLiAgIFRoZSBwZW9wbGUgdGhhdCBoYXZlIHNlbnQgbWFpbCBhcmUgYWN0aXZlbHkgZGVw bG95aW5nIExvU1QuIA0KPiANCj4gVGhlIGRyYWZ0IGlzIGV4cGlyZWQsIGFuZCBpdOKAmXMgc2hv cnQuICBJ4oCZbGwgcmVmcmVzaCBpdCB3aGVuIHRoZSB3aW5kb3cgb3BlbnMgYnV0IEnigJlkIGxp a2UgdG8gZ2V0IGl0IGFkb3B0ZWQgYW5kIG91dCB0aGUgZG9vciBzb29uLg0KPiANCj4gVGhlcmUg d2lsbCBhbHNvIGJlIGEgY291cGxlIG9mIGRyYWZ0cyBjb21pbmcgdGhhdCBhZGRyZXNzIG90aGVy IGludGVyb3BlcmFiaWxpdHkgaXNzdWVzIGRpc2NvdmVyZWQgaW4gTkVOQSDigJxJQ0XigJ0gZXZl bnRzLg0KPiANCj4gRGVwbG95bWVudCBleHBlcmllbmNlIGlzIGdvb2QhICANCj4gDQo+IEJyaWFu DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEVj cml0IG1haWxpbmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IEVjcml0IG1haWxpbmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQoNCg== From nobody Fri Jul 10 11:00:47 2015 Return-Path: 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 7C5F21A903E for ; Fri, 10 Jul 2015 11:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 nj3zQaLepcyh for ; Fri, 10 Jul 2015 11:00:44 -0700 (PDT) Received: from server907.appriver.com (server907.appriver.com [204.232.250.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B5E1A923D for ; Fri, 10 Jul 2015 11:00:43 -0700 (PDT) X-Note-AR-ScanTimeLocal: 7/10/2015 2:00:39 PM X-Policy: GLOBAL - UNKNOWN X-Primary: mserra@ravemobilesafety.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 7/6/2015 7:53:48 PM UTC X-Virus-Scan: V- X-Note: ICH-CT/SI:0-699/SG:1 7/10/2015 1:59:48 PM X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-440/SG:8 7/10/2015 2:00:06 PM X-GBUdb-Analysis: 0, 10.246.0.39, Ugly c=1 p=-0.986165 Source White X-Signature-Violations: 0-0-0-13126-c X-Note-419: 0 ms. Fail:0 Chk:1327 of 1327 total X-Note: SCH-CT/SI:0-1327/SG:1 7/10/2015 2:00:38 PM X-Note: Spam Tests Failed: X-Country-Path: ->->PRIVATE-> X-Note-Sending-IP: 10.246.0.39 X-Note-Reverse-DNS: X-Note-Return-Path: mserra@ravemobilesafety.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G256 G257 G258 G259 G263 G264 G378 G390 G395 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [10.246.0.39] (HELO smtp.us.exg7.exghost.com) by server907.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 6607776 for ecrit@ietf.org; Fri, 10 Jul 2015 14:00:39 -0400 Received: from DAGN04C-S1E7.exg7.exghost.local (192.168.244.55) by DAGN04C-S1E7.exg7.exghost.local (192.168.244.55) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 10 Jul 2015 14:00:39 -0400 Received: from DAGN04C-S1E7.exg7.exghost.local ([fe80::4cb2:4e3d:f0de:b4ed]) by DAGN04C-S1E7.exg7.exghost.local ([fe80::4cb2:4e3d:f0de:b4ed%22]) with mapi id 15.00.1104.000; Fri, 10 Jul 2015 14:00:39 -0400 From: Matt Serra To: "ecrit@ietf.org" Thread-Topic: Comments on draft-ietf-ecrit-additional-data-32 / Data Provider String Usage Thread-Index: AdC7OkiGQCP11gH+Rw6OXecRJ0SgCw== Date: Fri, 10 Jul 2015 18:00:38 +0000 Message-ID: <9101d605033c44db863e009c4893d4b5@DAGN04C-S1E7.exg7.exghost.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.244.1] x-exclaimer-md-config: 952e3d35-ca29-4b9e-94e1-a56fe70f6560 x-rerouted-by-exchange: Content-Type: multipart/related; boundary="_004_9101d605033c44db863e009c4893d4b5DAGN04CS1E7exg7exghostl_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [Ecrit] Comments on draft-ietf-ecrit-additional-data-32 / Data Provider String Usage X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 18:00:46 -0000 --_004_9101d605033c44db863e009c4893d4b5DAGN04CS1E7exg7exghostl_ Content-Type: multipart/alternative; boundary="_000_9101d605033c44db863e009c4893d4b5DAGN04CS1E7exg7exghostl_" --_000_9101d605033c44db863e009c4893d4b5DAGN04CS1E7exg7exghostl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable An observation on the latest draft: Section 4.1.1 Data Provider String: The Usage is documented as "Conditiona= l", yet the condition is not clearly specified - this may have been muddled= when we added guidance for how this field is populated by Devices. I suggest we change the Usage to Required, or minimally Optional. Regards, [rave_email_signature] Matthew A. Serra, ENP Sr. Director, Product Management Mobile: 201.245.1557 mserra@ravemobilesafety.com --_000_9101d605033c44db863e009c4893d4b5DAGN04CS1E7exg7exghostl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

An observation on the latest draft:

 

Section 4.1.1 Data Provider String:  The Usage = is documented as “Conditional”, yet the condition is not clearl= y specified – this may have been muddled when we added guidance for h= ow this field is populated by Devices. 

 

I suggest we change the Usage to Required, or minima= lly Optional.

 

Regards,

 

3D"rave_email_signature"

&nbs= p; Matthew A. Serra, ENP
  Sr. Director, P= roduct Management
  Mobile:  201.245.1557
  mserra@ravemobilesafety.com

 

 

--_000_9101d605033c44db863e009c4893d4b5DAGN04CS1E7exg7exghostl_-- --_004_9101d605033c44db863e009c4893d4b5DAGN04CS1E7exg7exghostl_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3039; creation-date="Fri, 10 Jul 2015 18:00:38 GMT"; modification-date="Fri, 10 Jul 2015 18:00:38 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAKoAAAA4CAYAAABt2GPKAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ bWFnZVJlYWR5ccllPAAAAyJpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdp bj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6 eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMC1jMDYwIDYxLjEz NDc3NywgMjAxMC8wMi8xMi0xNzozMjowMCAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJo dHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlw dGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAv IiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RS ZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtcDpD cmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHhtcE1NOkluc3RhbmNl SUQ9InhtcC5paWQ6RTRDQ0FBRDE4ODI2MTFFMzkwNzRCNERGRkY0MDc3Q0YiIHhtcE1NOkRvY3Vt ZW50SUQ9InhtcC5kaWQ6RTRDQ0FBRDI4ODI2MTFFMzkwNzRCNERGRkY0MDc3Q0YiPiA8eG1wTU06 RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDpFNENDQUFDRjg4MjYxMUUzOTA3 NEI0REZGRjQwNzdDRiIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDpFNENDQUFEMDg4MjYxMUUz OTA3NEI0REZGRjQwNzdDRiIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1w bWV0YT4gPD94cGFja2V0IGVuZD0iciI/PlzaqucAAAhTSURBVHja7F1bbttGFB0H+Y8W0ALsd9HG XoGlFVj+LVqIXoGsFchegaUVmAKK/kZZgekVhEXRb7NA/6uuwJ3r3gkmjETeMxyKD88FFCUK533m 3MfckU6en59VkCBdl7f0x7c//tIGWnf6lenXo35t//7j1+yYjX/zw88j/fakXyNhkVT3cSKo91S/ fQK68p2uN/c8tgf9NhY+nuj2r6yyVO6hYzidvGmx8RFP5pIWVk/Qk35dM4COIdcASEnGvIilwhsu BeqNPYM0AkBKsu4Do77pUF9ogu8YtOMmG+LNMHcouhQ+twHqnHse3hJ4Nj22JhsCUG3APmgwxQ22 gbIpyqqJfpOq85GvsfIGnA6NTbsKVCP3TYC1Bps2yaozT8OLgQ2Y6w21DUD1B9bTjrApxKpaVmCd PsaJbMDesOlnrx+QHGQKW85BI98I2a0TH4P1wKY2q6YV6n+n20sAZ4n6dVVjbFM2myRCEZdk0EDV C3BTEyjXoMFPbBN5CuHUZdMvWFX3qcq7XwNAneo6FwRwxz4h5kNSox1bbuvgobOqnyaHB3YJFp3W bdsjm4ptVfaopV71SDmGqjgkNUgnqlUblY34FCjigwWlbCoFltRWRUDhupGQclvfBwxDd6Yej9UQ yKYLWkyPrJqwTSiRiG1NdGwIE/eOTfvg9R/b00/Z7pQuZhOsioaqpoDGyQR2dQBqDXE+PQHZdM0s mAJtShxDxMOess3ZhNrvJZu2DdQL4Nk6LCBl02IA3Bursk2Y+AYftyuNv+7YDOmlvG2jUT5xkk6w cygFZNPbom2pyxNbSthtJthMG8CWjNlW9mkmNMGm53qObhqESmIcv7dHBigaR90VAdQgmyYHFvdO Aiw9ttsyb5rMCf1MJtygL+f/ZQzI5gHiRK0aWNKxcjvEQTSpE1Ajxx30jhcIHdSVayilDpsWbMul EOz0XNXJEgH/HlD/SQXrIsy0Uz0WGKgKO1VyFQLnZc0UNCmb0gJuD7AgHYOuhWOWsCqZE3fCfp3S +X/JHLwKJ6qrXr9R9Wd1QIp6+hVsgzggS8+gmZfY+MjNhCwA1Z9kDNAbD2oKYdOVR489FoSWEODH B248tO1EvWqgkg1L11HuwThiHTaV2m6IQ7f0CPyvbFFOB5Ta+r3KOfVpox5DaGEo6D1xVFlIhpSI bQhcuj+pECCVtqrCQlXzAut3yTZNlHvap1TLOgE1Bzv2nkETKXmupOIydB3lDPH6QTbNGVSI/Yyw 6lUJ8ClUlQvn5OX8n5gRPNc/Rs7pX8c6kj1aPiqrrDkw0SMO5SBJ0wibNhnBkLDqrZKHqmYcmYiB PvQ+JNWKjUpqnO+PI1ns4isaDeSb1pWqTbAFWNqc/7+qkFSrzhSftiAqSZr25it73yerRiXzgKrm D4D51Muc0y56/YgXfd5DNpWyKsJ6yOW/QbFpa0Dl3S716CUs0jU2lbJqruRJ2ogfkQ4NqG2Gp6QJ GpFHNt2pGrmtBUdPynBVOQBr5eFOmKO2CkCVhDY81YOw6cJHTiZvjn98RADAUFXlRuxzzmlXgZqq muEhNG7qaxEd7+wvKljw3kPXjm2bLjlnt3Gs9OIqSkkGPcKmvk9QEBUbV3xLIRKqKpNBsmmbXr+q a/A72KYrz/3PlfyKjEkYP8jQHkCWDC0k1QmggjKuyabrhk5pEFadV7BqXbW9VgOWtoEq9cDf12DT xlQieFu1ilVz5R6qGkTOaZeBKlWdxSvECJs2rRKhROiGWHWjBi5tAxWZ4PuCF92EenZhVWJr6Uao YtUUqMt7NKPTEn4VJUhg1CBBPMlLwP/fn74fh6kI0nmgqu79rlCQIHuBOglTESQ4U0GCBGcqyGty poyNevvutz9T85/6c4pdRvq10Z8nZRXpZ02M0GTk51xfXtUJq31lld3YfTlQLlb/X3xb6Gezquf0 M2ITR5ehfNN9X5BWORdAGzfWfO14vjJhWZrri+KaOYynau72+i9lc3mojJZMl1tUzMXn8ejPCHuE wcww6phfM6sgPRTz55Fg7qhzSwYZDZySgT/xBFVJsQ0q+8B9KJOIy46EzyEyEtZdB6QmRS7jtiRj NrIsrllD46Eyrr+BFQFtJtyOfbBzx+U/FvNRCSAmGz0GJj3mRmh3rvgzOnX6xBMq+RUUYqobqz7D 5rlqVxYSxnKQc5uZ9JjpNw0+SMasnzVfh079ivW/qY+7BseTIdrIGpPZjJVtkubVz798IR2XSxmP CZW1gUoJEVMCCau2GU+YZIdfcGMrq+FM12UaEy0cd9DU5+vaSF2ZFeLMicScEQgBc6zrfuK5f9T1 nkj7xGuzYDKgjb1yGE8uNGMia21I0iY2LxGVbofWfm5hYGGHp0h+Z1a80A9nDNCVKjmbLqiVvTsR ULnRnr9HHQBrUbOkPlieF2XHC0JzfM3/PivbCGwa0OZfMRnk6uuv/ZGOJ1WyzLJIfX0bI21ovhds RhIWr4ymKKr+DXdox6+PQqDmZhILkzxW8sx1W/WbO0m1fnbRk0yaYA+j3kgL8Xhjtsno/UYAtGt2 qEx9Y2E/XcaTIqq/5gZOWROPbbZ/s8egNZOBeLYmC+qOJ922W11S107V8IU24T1vbsTMmfGzE35d Wp8POzxVMGjNNeaN1EPkXXDLbDxlFWaMfalKIiPaVi875TlrXdf/XOi3xCYkT7wJdlmww/hkzVfp lRR2oqKic8JrNgWdKsjzd5w770CdWHYX7dCI7Z9R4f+qbK6t5TyRpyjNWJ/sA78wpJEK2ChxsKky tf9o2QsQSK1ZzuaI53hbATTTp+J4LwVO76Gy8NoAIl2ffZv4C5I8CUeoQfog4Qg1SC/kPwEGAAO+ sOGPE+6YAAAAAElFTkSuQmCC --_004_9101d605033c44db863e009c4893d4b5DAGN04CS1E7exg7exghostl_-- From nobody Fri Jul 10 11:47:20 2015 Return-Path: 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 C2D0E1A88FA; Wed, 8 Jul 2015 15:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 zp_2o13Vx06C; Wed, 8 Jul 2015 15:33:23 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BBF21A88AE; Wed, 8 Jul 2015 15:33:23 -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=1436394803; x=1467930803; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=x7/KUtBEEKjiyg6Zb2Z8/fzOuP0gZT8YDLTqTVRZYTw=; b=tP7Q7h4jN75a0T6JQ7N4gAPuGDusnh9e/Qts0wh6soHM+1NTMZzr+AfM eElgLTx0bKQAJuWrmXFsWVk6QeG7b+mkKnEfdZuDXGK3OLen0Qh9jDAuE Oy/GZtRAYdjYFpNxkjNODUK5InsGJhRCstb0NHdP6e9uTwfynu/SGh+oF I=; X-IronPort-AV: E=McAfee;i="5700,7163,7856"; a="219530378" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2015 15:33:23 -0700 X-IronPort-AV: E=Sophos;i="5.15,434,1432623600"; d="scan'208";a="956225968" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Jul 2015 15:33:21 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 8 Jul 2015 15:33:20 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Wed, 8 Jul 2015 15:33:18 -0700 To: "Rosen, Brian" , Randall Gellens , Bernard Aboba , Gunnar Hellstrom , Hannes Tschofenig , Henning Schulzrinne , Ban Al-Bakri , Barry Leiba From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 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: X-Mailman-Approved-At: Fri, 10 Jul 2015 11:47:19 -0700 Cc: "slim@ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] [Slim] Time in Prague to discuss SLIM real-time draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 22:33:24 -0000 Would the first afternoon session (starts at 1:00) work? Ban doesn't land until 11:00, so lunch would be cutting it close. At 5:39 PM +0000 7/8/15, Brian Rosen wrote: > Hmmm, I think Monday lunch works for me this meeting (no more Apps chair > lunch). > > On 7/8/15, 1:30 PM, "Randall Gellens" wrote: > >>I'd like to set a time to meet in Prague so that Bernard, Brian, >>myself, and anyone else interested can talk in depth about the SLIM >>real-time draft. Would Monday lunch work? If not, please suggest >>some alternate times. >> >>-- >>Randall Gellens >>Opinions are personal; facts are suspect; I speak for myself only >>-------------- Randomly selected tag: --------------- >>You never finish a program, you just stop working on it. > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The spirit of this country is totally adverse to a large military force. --Thomas Jefferson From nobody Fri Jul 10 11:47:22 2015 Return-Path: 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 8B6EF1A9166; Fri, 10 Jul 2015 07:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 dwO0uisXErMv; Fri, 10 Jul 2015 07:51:16 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3470F1A9151; Fri, 10 Jul 2015 07:51:16 -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=1436539876; x=1468075876; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=J/07/dQSuzIvw/3hgu2Ki3/bWV30PYxJPs8gGzuxeUM=; b=StO3SSgf1pkxpMeE2xQwXLaWFT2KzG5U5JlpoUV+9j8eHDa4umCdYLUU ux5yFeYgpk+Li/MR/eq3D/cShKEh+zZwfzAKgIyjUIlZ0QZMPiF4zT0sR osMTqXpODUSPAPWtigH2L73l6xQhlv8TVlACeSQ+JnlUA3DjlUK+XT1Wm A=; X-IronPort-AV: E=McAfee;i="5700,7163,7857"; a="127223994" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine01.qualcomm.com with ESMTP; 10 Jul 2015 07:51:15 -0700 X-IronPort-AV: E=Sophos;i="5.15,447,1432623600"; d="scan'208";a="32960866" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Jul 2015 07:51:14 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 10 Jul 2015 07:51:13 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Fri, 10 Jul 2015 07:51:06 -0700 To: Bernard Aboba , Henning Schulzrinne , Brian Rosen From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 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: X-Mailman-Approved-At: Fri, 10 Jul 2015 11:47:19 -0700 Cc: "slim@ietf.org" , ECRIT , Barry Leiba , Brian Rosen , Randall Gellens Subject: Re: [Ecrit] Time in Prague to discuss SLIM real-time draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 14:51:17 -0000 Would the first afternoon session (starts at 1:00) on Monday work? At 6:09 AM -0700 7/10/15, Bernard Aboba wrote: > I will be in Prague from Saturday through Friday. I cannot do > Monday lunch but other days are OK. > > > On Jul 9, 2015, at 7:26 PM, Henning Schulzrinne > <hgs@cs.columbia.edu> wrote: > >> I'm in Prague Sunday afternoon through Thursday morning, and >> fairly flexible. Thanks for organizing! >> >> On Wed, Jul 8, 2015 at 1:30 PM, Randall Gellens >> <randy@qti.qualcomm.com> wrote: >> >> I'd like to set a time to meet in Prague so that Bernard, Brian, >> myself, and anyone else interested can talk in depth about the >> SLIM real-time draft. Would Monday lunch work? If not, please >> suggest some alternate times. >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> You never finish a program, you just stop working on it. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Howe's Law: Everyone has a scheme that will not work. From nobody Fri Jul 10 11:47:23 2015 Return-Path: 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 068C31A92F0; Fri, 10 Jul 2015 08:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KpCOM74k_cR1; Fri, 10 Jul 2015 08:10:14 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C951AD37B; Fri, 10 Jul 2015 08:10:14 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6AF9mLG016326 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 10 Jul 2015 10:09:59 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Randall Gellens" Date: Fri, 10 Jul 2015 10:09:48 -0500 Message-ID: <6A6DE46B-F440-4CE6-8ACA-49CC7ECCFBDF@nostrum.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: X-Mailman-Approved-At: Fri, 10 Jul 2015 11:47:19 -0700 Cc: "slim@ietf.org" , ECRIT , Barry Leiba , Brian Rosen Subject: Re: [Ecrit] [Slim] Time in Prague to discuss SLIM real-time draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 15:10:16 -0000 I personally need to be in clue at 1pm Monday. Of the other times mentioned, I think I could do Tuesday lunch. With this many people, perhaps a doodle would be helpful? On 10 Jul 2015, at 9:51, Randall Gellens wrote: > Would the first afternoon session (starts at 1:00) on Monday work? > > At 6:09 AM -0700 7/10/15, Bernard Aboba wrote: > >> I will be in Prague from Saturday through Friday. I cannot do Monday >> lunch but other days are OK. >> >> >> On Jul 9, 2015, at 7:26 PM, Henning Schulzrinne >> <hgs@cs.columbia.edu> wrote: >> >>> I'm in Prague Sunday afternoon through Thursday morning, and fairly >>> flexible. Thanks for organizing! >>> >>> On Wed, Jul 8, 2015 at 1:30 PM, Randall Gellens >>> <randy@qti.qualcomm.com> wrote: >>> >>> I'd like to set a time to meet in Prague so that Bernard, Brian, >>> myself, and anyone else interested can talk in depth about the SLIM >>> real-time draft. Would Monday lunch work? If not, please suggest >>> some alternate times. >>> >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself >>> only >>> -------------- Randomly selected tag: --------------- >>> You never finish a program, you just stop working on it. > > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself > only > -------------- Randomly selected tag: --------------- > Howe's Law: > Everyone has a scheme that will not work. > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim From nobody Fri Jul 10 11:47:24 2015 Return-Path: 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 8F56F1A1AD3; Fri, 10 Jul 2015 11:39:51 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 bBK1FNM5Hg9p; Fri, 10 Jul 2015 11:39:50 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E2B1A1ACC; Fri, 10 Jul 2015 11:39:50 -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=1436553590; x=1468089590; h=message-id:in-reply-to:references:date:to:from:subject: cc; bh=7a9Y3cMVo75dGCOuR+9YX9o7gJeZSY7jBVIInTZnH8I=; b=K190yXKS6xxuCubTPYhv9Cldu5yV4o3ovzwirLw383DcoJUU24xH01oY dV2tH8olqlCxwrR+GcoCGsHdMiYjM8jJuJLGZWhctTLpNk0woN06O0TV/ 6/Vi2p+8FaF3PSDMNPIqjkh2CIrFP8Hm3W26nytK5Lfa2k7GyGlOk4TGN Y=; X-IronPort-AV: E=McAfee;i="5700,7163,7858"; a="127248699" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2015 11:39:43 -0700 X-IronPort-AV: E=Sophos;i="5.15,448,1432623600"; d="scan'208";a="932575150" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2015 11:39:42 -0700 Received: from Ironmsg03-L.qualcomm.com (ironmsg03-L.qualcomm.com [172.30.48.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t6AIdfAJ019723; Fri, 10 Jul 2015 11:39:42 -0700 X-IronPort-AV: E=Sophos;i="5.15,448,1432623600"; d="scan'208";a="957935261" X-ojodefuego: yes Received: from unknown (HELO [99.111.97.136]) ([10.64.162.243]) by Ironmsg03-L.qualcomm.com with ESMTP; 10 Jul 2015 11:39:39 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <6A6DE46B-F440-4CE6-8ACA-49CC7ECCFBDF@nostrum.com> References: <6A6DE46B-F440-4CE6-8ACA-49CC7ECCFBDF@nostrum.com> X-Mailer: Eudora for Mac OS X X-Priority: 2 (High) Date: Fri, 10 Jul 2015 11:39:38 -0700 To: Bernard Aboba , Brian Rosen , Hannes Tschofenig , Henning Schulzrinne , Nik Tomkinson , "Ben Campbell" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: X-Mailman-Approved-At: Fri, 10 Jul 2015 11:47:19 -0700 Cc: slim@ietf.org, Nathaniel Borenstein , ECRIT , Chris Newman , Barry Leiba Subject: [Ecrit] Tuesday Lunch in Prague to discuss SLIM real-time & email (both) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 18:39:51 -0000 It seems that Tuesday lunch works for everyone interested in the SLIM real-time and email work, so let's settle on that for both. Please confirm your attendance to me today if possible, and if we have enough I will reserve a room at a restaurant in the hotel, so we can talk and be heard. If we can meet pretty quickly after the morning session ends, we can have time for both topics. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I don't want to achieve immortality through my work.... I want to achieve immortality by not dying.- --Woody Allen From Jerry.Schlesinger@portlandoregon.gov Fri Jul 10 13:52:35 2015 Return-Path: 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 60DB71A00F9 for ; Fri, 10 Jul 2015 13:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 7vg-knpDYd93 for ; Fri, 10 Jul 2015 13:52:33 -0700 (PDT) Received: from smtp1.portlandoregon.gov (smtp1.portlandoregon.gov [74.120.152.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2696F1A00F7 for ; Fri, 10 Jul 2015 13:52:33 -0700 (PDT) Received: from smtp1 (127.0.0.1) id hk0o920171sd for ; Fri, 10 Jul 2015 13:52:33 -0700 (envelope-from ) Received: from HUB3.rose.portland.local ([10.106.253.11]) by smtp1 (SonicWALL 7.4.9.2791) with ESMTP id 201507102052320147409; Fri, 10 Jul 2015 13:52:32 -0700 Received: from MAIL3.rose.portland.local ([fe80::e8b9:f9a7:3821:f9a4]) by hub3 ([10.106.253.11]) with mapi; Fri, 10 Jul 2015 13:51:40 -0700 From: "Schlesinger, Jerry" To: "ecrit@ietf.org" Date: Fri, 10 Jul 2015 13:52:31 -0700 Thread-Topic: I support https://tools.ietf.org/html/draft-rosen-ecrit-lost-planned-changes-01 Thread-Index: AdC7UgTHNlF8Qf8DS4um3pohLwOIkQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_D827A73CD34D284785E2B7C567C3D9014D462213F3MAIL3roseport_"; type="multipart/alternative" MIME-Version: 1.0 X-Mlf-Version: 7.4.9.2791 X-Mlf-UniqueId: o201507102052320147409 Archived-At: Subject: [Ecrit] I support https://tools.ietf.org/html/draft-rosen-ecrit-lost-planned-changes-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 20:54:25 -0000 --_004_D827A73CD34D284785E2B7C567C3D9014D462213F3MAIL3roseport_ Content-Type: multipart/alternative; boundary="_000_D827A73CD34D284785E2B7C567C3D9014D462213F3MAIL3roseport_" --_000_D827A73CD34D284785E2B7C567C3D9014D462213F3MAIL3roseport_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I read the following document: "Validation of Locations Around a Planned Ch= ange: draft-rosen-ecrit-lost-planned-changes-01" and would like to see it p= rogressed in the IETF Thanks - Jerry ---------------------------- Jerry Schlesinger, PMP RegJIN RMS Project Manager -- PSSRP City of Portland - Portland Police Bureau 1111 S.W. 2nd Avenue, Suite 1156 Portland, Oregon 97204 Voice: 503.823.6902 Mobile: 503.823.8810 Email: Jerry.Schlesinger@portlandoregon.gov [cid:image001.jpg@01D0BB17.AAC91090] This e-mail, and any attachments thereto, is intended only for use by the a= ddressee(s) named herein and may contain legally privileged and/or confiden= tial information. If you are not the intended recipient of this e-mail (or = the person responsible for delivering this document to the intended recipie= nt), you are hereby notified that any dissemination, distribution, printing= or copying of this e-mail, and any attachment thereto, is strictly prohibi= ted. If you have received this e-mail in error, please respond to the indiv= idual sending the message, and permanently delete the original and any copy= of any e-mail and printout thereof. Public Records Law Disclosure: This e-mail is a public record of the City o= f Portland and is subject to public disclosure unless exempt from disclosur= e under Oregon Public Records Law. This email is subject to the City of Por= tland's Retention Schedule. --_000_D827A73CD34D284785E2B7C567C3D9014D462213F3MAIL3roseport_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
I read the following document: “Validat=
ion of Locations Around a Planned Change: draft-rosen-ecrit-lost-planned-ch=
anges-01” and would like to see it progressed in the IETF=
=

 

 

Thanks – Jerry

----------------------------

Jerry Schlesinger, PMP

 RegJIN RM= S Project Manager -- PSSRP

City of Portland – Portland Police Bureau

1111 S.W. 2nd Avenue, Suite 1156

Portland, Oregon 97204

Voice:  503.823.= 6902

Mobile: 503.823.8810

Email: Jerry.Schlesinger@portlandoregon.= gov

3D"cid:image001.jpg@01D01864.7=

 

 

This e-mail, and any attachments thereto, is intended onl= y for use by the addressee(s) named herein and may contain legally privileg= ed and/or confidential information. If you are not the intended recipient o= f this e-mail (or the person responsible for delivering this document to th= e intended recipient), you are hereby notified that any dissemination, dist= ribution, printing or copying of this e-mail, and any attachment thereto, i= s strictly prohibited. If you have received this e-mail in error, please re= spond to the individual sending the message, and permanently delete the ori= ginal and any copy of any e-mail and printout thereof.

Public Re= cords Law Disclosure: This e-mail is a public record of the City of Portlan= d and is subject to public disclosure unless exempt from disclosure under O= regon Public Records Law. This email is subject to the City of Portland's R= etention Schedule.=

 

 

= --_000_D827A73CD34D284785E2B7C567C3D9014D462213F3MAIL3roseport_-- --_004_D827A73CD34D284785E2B7C567C3D9014D462213F3MAIL3roseport_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=3114; creation-date="Fri, 10 Jul 2015 20:52:31 GMT"; modification-date="Fri, 10 Jul 2015 20:52:31 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAA4ALQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2SqOr 61YaFZm61K5SCLoM8lj6AdSaTXNYttA0ifULs/u4l4UdXbso9ya8Iu7vWPHviMYVpriU4jiU/JEn 9AO5rOdTl0W53YPB+3vKTtFbs7HVvjLKXZNH05Ag6SXJyT/wEdPzrFHxa8Rh92bMj+75PH8810um fDrw5oaK/iTUbea5IyY5JxFGPoMgn8fyrp7Lw/4RvYytlY6TcKBz5QRz+YrO03uzrdXB01aNO67/ APDnI6P8ZAzrHrOnhVPWW2PT/gJ/xr0fTdUs9Ys0u9PuEngboyHofQjsfY1ymtfCvQ9RiY2KPp8+ OGjJZM+6n+mK8+hfW/hj4jAlXMT/AHlB/d3Ke3uPzFPmnD4tiHQw+KT9hpLs+p7tWVN4p0K3mlin 1iwilhYpIjzqrKR1BBNW9N1G31bToL6zffBOgdT/AEPuOleffEu2gPjHwk5hjLS3QVyVHzjzI+D6 jk/nW55TTTsztrTxTod9OIbXV7GWU9EWddx+gzzWrXM+PNE07UPCGpNc20O+CB5YpdgDRsoyCD26 VF8M9Qu9S8DWUt87ySIXjWRzksqsQCT39PwoEdBqWrWOjWpudSu4bWEHG+VsZPoPU+wrLs/HXhq/ uVt7fWLYzOcKjkoSe2NwFcn4h1O2034v2UviAAactnttHkGY43J5b654J7ZFdT4q8K2HjDRTGrQp PgPbXaKGKHsQR1B9M0AdFVTUtWsdGtTc6ldw2sION8rYyfQep9hVpAVRQxyQACfWvNfEGp2+m/GC zl8QADTls9to8gzHG56t9c8E9sigDrLPx14av7lbe31i2MzHCo5KEn23AVv1z3inwtYeMNFMatCs +A9tdooYoeoOR1B9M10CAqihjuYAAn1oAzLrxPollcyW91q1lDPEcPHJMqsvGeQTTLfxboF3MsUG s2DyN91RcLk/TnmuM+MVvCy6DKYkMjXoQttGSvHBPpXUeNtI0y78I6n9tt4NsVs7o5QAxsBlSD25 AoA6Kqeoavp+lCM6je29qJSVQzSBAxHYE1zXwquru78B2jXrO5V3SJnOSYwcDnvjkfhW34rgiuPC erLNGkii0lYBlzghCQfrQBG3jLw4jbW1zTgf+vhf8a1be5gvIFmtZo5om+68bBlP4iuL+FFrby/D 618yCJ98ku7cgO75yOfWsvw+n9hfGXUdI0v93p08PnSW6/cRtqtkDoOT/wCPUAem0UUUAeS/GPV2 kv7LSUY+XEnnyAd2OQPyAP51H4K028uYm03RZDaZAbU9SAy4J6QxntgdT659BnG+KLMfHl7uzgJG B9Ngr1jwNpSaR4Q0+JVAeWMTyn1Zxn+WB+FcyXNUZ7lWaoYOCXX/AIcfp3g3Q9NX93p8U0p+9Ncj zZGPqS39KsXPhrSLnBbT4I5F5WWFfKkU+oZcEVqUV0cq7HjurUbu5MyLaa60q7js76Y3FtMdtvdP gOG7JJjgk9m79Dz1TxR4eg8TaJNZTBRJjdDIRzG/Y/0PtWhqFoL6wmtycF1+Vv7rdVP1BwfwpNNu je6bbXDAB5Y1ZgOxxz+tK3RjU2mqkdGjz34Q6jNF/aWh3WQ9s/mop/h52uPzx+ZpfiksreJvCa27 rHMbkiN3XcFbfHgkdxntT9Gt/snxs1VI+FkgaQgf7QRj+pqbxvo/iDW/EmlXOnaQHg0qbzA8lyi+ f8ytwM5A+XHNTT+G3Y3x1nV519pJ/eauoeFNY8QQ/Zdd11TYEgyW9jbeUZcdmYsxx7CulsrK306y htLOJYbeFQkaL0UCksJ7i5s45by0NpO2d0JkD7ef7w4NWK0OMztc0DTvEVibTVLZZo+qnoyH1U9Q a82v9G8QfC4tqOi3jX2iKw862m/gBPcdB/vLj3FdNq9r4j0TxbLq+h2v9pafeRoLqzMwVldRgMme Bxj/ADimay/iHxhpMukxaG+lQXOEnuryZGKJnJ2opJJ474FAHW6XqEWraXa39vkRXMSyqD1AIzg1 Brmgad4isTaapbLNH1U9GQ+qnqDVjTbCLS9NtrG3z5VvEsSZ64AxXKava+I9E8Wy6vodr/aWn3ka C6szMEZXUYDJngcY/X2NAHM3+jeIPhcW1HRbxr7RFYedbTfwAnuOg/3lx7ivUNL1CLVtLtb+3yIr mJZVB6gEZwa5PWX8Q+L9Jl0mLQ30qC5wk91eTIxRM5O1FJJPHfArrdNsItL022sbfPk28SxJnrgD HNAHA/GME2ughW2sb4ANjODjrWd4khvbfxrp+meL9Tub7QLzHlsMQIX9HCAA4OPwYHtW18RdF13x HcWEGl6WHisphP58lwiiQ4+6BnP4mt3UtFHjPw29pr2ntYzMxKASrI0TDo6sOPw+tAG7b20Nnbx2 9tEkUMShURBgKB0AFUfEv/Irat/15Tf+gGsnww/iHS/L0jXLQ3ccY2w6nA6lWUDjzFJ3A9sjP9a0 fFIvpdAurXTbFrye6ieAASqgTcpG4lj0HtQBxXw4s/EFx4Jtf7O1WztLVnkAD2ZkkQ7zk53AHn1F dd4b8I2nh2W5uvOmvNRuzm4vJyN7+wA4A9hWX8O9P1rQdHi0jVNLWKOIu63KXCOCS2cFRyOv6V2V ABRRRQB478YdLaDXrXUFB8u5h2E/7a//AFiPyr0rwjfJqPhPTLiMjBt0QgdmUbSPzBpPFfh2LxPo U1jIQkn34ZCPuOOh+nY+xrzLwZ4qn8DapcaNrsUkdqZPm4yYX/vD1U8dPqKx+Cd3sz1VfFYVQj8U OndHs1FQ2l5bahbrcWc8c8LDIeNgwNSSyxwRNJM6xxqMsznAA9ya2PLs72GXVzHZ2k1zKcRwoXY+ wGaraJC8GiWUcq7ZBCpZfQkZI/Wsr7X/AMJZcpFaBjo0LhprgjAumU5CJ6oCMluhxgd6TxXrk0W3 RdH/AHus3q7UCn/UIesjegA6VPMtzZUm7Q69fL1MrwfH/anjnxHri/NAHFpC3ZsYzj/vlfzruazt A0WDw/otvp9tysS/M5HLseSx+prRoirIVeopzutlovRBRRRVGIUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFYXibwhpvim3C3iFLhBiO4j4dfb3HsaKKTSejKhOUJc0XZnAD4e6zoEzNbxS30JP+ tsbw282PcHIrRtrGBZFa+8L+JNRlXlRezCVAfoWCn8RRRWTgo7HoRxU6qvLf5r9TpPM8Uaqght7S 20K2xt8yRxNMB/sqvyj8TWnovh+z0OOQwb5bmY7p7mZt0sp9WP8ATpRRWij1OKVVtcq0XkalFFFU ZBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf//Z --_004_D827A73CD34D284785E2B7C567C3D9014D462213F3MAIL3roseport_-- From nobody Fri Jul 10 13:59:23 2015 Return-Path: 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 E23CA1B2D08 for ; Fri, 10 Jul 2015 13:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 wkKWUlLw1C71 for ; Fri, 10 Jul 2015 13:59:18 -0700 (PDT) Received: from server907.appriver.com (server907a.appriver.com [204.232.250.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6461A1A0091 for ; Fri, 10 Jul 2015 13:58:46 -0700 (PDT) X-Note-AR-ScanTimeLocal: 7/10/2015 4:58:44 PM X-Policy: GLOBAL - UNKNOWN X-Policy: GLOBAL - UNKNOWN X-Primary: mserra@ravemobilesafety.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 7/6/2015 7:53:48 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-250/SG:2 7/10/2015 4:58:01 PM X-GBUdb-Analysis: 0, 10.246.0.39, Ugly c=1 p=-0.98857 Source White X-Signature-Violations: 0-0-0-5593-c X-Note-419: 15.6309 ms. Fail:0 Chk:1327 of 1327 total X-Note: SCH-CT/SI:0-1327/SG:1 7/10/2015 4:58:43 PM X-Note: Spam Tests Failed: X-Country-Path: ->->PRIVATE-> X-Note-Sending-IP: 10.246.0.39 X-Note-Reverse-DNS: X-Note-Return-Path: mserra@ravemobilesafety.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G256 G257 G258 G259 G263 G264 G378 G395 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [10.246.0.39] (HELO smtp.us.exg7.exghost.com) by server907.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 12349595; Fri, 10 Jul 2015 16:58:44 -0400 Received: from DAGN04C-S1E7.exg7.exghost.local (192.168.244.55) by DAGN04B-S1E7.exg7.exghost.local (192.168.244.51) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 10 Jul 2015 16:58:44 -0400 Received: from DAGN04C-S1E7.exg7.exghost.local ([fe80::4cb2:4e3d:f0de:b4ed]) by DAGN04C-S1E7.exg7.exghost.local ([fe80::4cb2:4e3d:f0de:b4ed%22]) with mapi id 15.00.1104.000; Fri, 10 Jul 2015 16:58:43 -0400 From: Matt Serra To: Randall Gellens , "ecrit@ietf.org" Thread-Topic: Comments on draft-ietf-ecrit-additional-data-32 / "Data About" registry Thread-Index: AdC7ULaWJ+95XMsyRDezNDm/7e9+VA== Date: Fri, 10 Jul 2015 20:58:43 +0000 Message-ID: <9e52f2a2f2d54c0c97257a444a61559e@DAGN04C-S1E7.exg7.exghost.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.244.1] x-exclaimer-md-config: 952e3d35-ca29-4b9e-94e1-a56fe70f6560 x-rerouted-by-exchange: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Ecrit] Comments on draft-ietf-ecrit-additional-data-32 / "Data About" registry X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 20:59:21 -0000 Randall & WG: The NENA Add'l Data WG reviewed some of the recent changes (through v32) th= is past Monday. We have two comments (and a NIT) on the recently added Emergency Call Data= Types Registry (section 10.1.9) 1. To support future growth, we suggest the "Data About" field support mul= tiple values per token. As defined here, only one value per token is allow= ed. This does not support cases where a Token could be used to communicate= more than one form of data, but less than "All" forms of data. Here is th= e current text. Proposed changes _from_ this: " The value MUST be _either_ "The Call", "The Caller", "The Location", or = "All". New values are created by extending this registry in a subsequent R= FC." _To_ this: " The value MUST be _one or more of_ "The Call", "The Caller", "The Locatio= n". New values are created by extending this registry in a subsequent RFC.= " 2. Our group was a confused by what affect the values in this registry have= on the XML, noting the text describing "Data About" can be interpreted to = imply Data About is passed in the XML so it can be inspected by the PSAP: = "Indicates if the data describes the call, the caller, or the location (or= is applicable to all), which helps PSAPs and other entities determine if t= hey wish to process the block." Additionally, please consider changing the _following text_ for clarity: "Note that the _values_ from this registry are part of the 'EmergencyCallDa= ta' compound value; when used as a value of the 'purpose' parameter of the = Call-Info header, the _values_ listed in this registry are prefixed by 'Em= ergencyCallData.' per _the the_ 'EmergencyCallData' registration" To this: "Note that the _tokens_ from this registry are part of the 'EmergencyCallDa= ta' compound value; when used as a value of the 'purpose' parameter of the = Call-Info header, the _tokens_ listed in this registry are prefixed by 'Em= ergencyCallData.' per _the_ 'EmergencyCallData' registration" Finally, a NIT: you will see the last phrase if the above passage repeats t= he word "the" Regards, Matt. From nobody Fri Jul 10 14:52:56 2015 Return-Path: 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 35E6C1B2D12 for ; Fri, 10 Jul 2015 14:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 xqln1tBx8sz1 for ; Fri, 10 Jul 2015 14:52:53 -0700 (PDT) Received: from bin-vsp-out-04.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79491B2D0B for ; Fri, 10 Jul 2015 14:52:52 -0700 (PDT) X-Halon-ID: ffc53ca5-274d-11e5-b1e0-005056917c0c Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.42] (unknown [87.96.160.92]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Fri, 10 Jul 2015 23:52:46 +0200 (CEST) Message-ID: <55A03EAF.6040504@omnitor.se> Date: Fri, 10 Jul 2015 23:52:47 +0200 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Randall Gellens References: <6A6DE46B-F440-4CE6-8ACA-49CC7ECCFBDF@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "slim@ietf.org" , ECRIT Subject: Re: [Ecrit] [Slim] Tuesday Lunch in Prague to discuss SLIM real-time & email (both) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 21:52:54 -0000 Yes, I want to participate remotely, if you manage to arrange for calling in. /Gunnar Randall Gellens skrev den 2015-07-10 20:39: > It seems that Tuesday lunch works for everyone interested in the SLIM > real-time and email work, so let's settle on that for both. Please > confirm your attendance to me today if possible, and if we have enough > I will reserve a room at a restaurant in the hotel, so we can talk and > be heard. If we can meet pretty quickly after the morning session > ends, we can have time for both topics. > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Thu Jul 16 17:40:04 2015 Return-Path: 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 6D1641B2C11 for ; Thu, 16 Jul 2015 17:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 bvMR8qNkyBwC for ; Thu, 16 Jul 2015 17:40:00 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 785091B2BF6 for ; Thu, 16 Jul 2015 17:40:00 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C86A2205BF for ; Thu, 16 Jul 2015 20:39:59 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Thu, 16 Jul 2015 20:39:59 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=5ZIEur3IvkOpOG5RHfkddVc/qyA=; b=bThPfW 0GKHmttXWCf3LyUx6Z3Sg2cTJ35Mz3b0vWfLJnJ22c5rzuWS0g7RpVcpui9sOzl6 zOGDAPl511BGZSjUtVKO0kFODYaH/7ZUG/bCO0ICS7efQCEU46RK7paTZI3i+F98 2xwooe2eDI16tMajIgpM+rGpjLCpVPSxS7rQM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=5ZIEur3IvkOpOG5 RHfkddVc/qyA=; b=q2LsynwiKN+HZNUOKyNno5M+IxAWXudpMahYfWnkGrcfoy7 +fNe23ggW+pOd3Yn2ySoQTkoV12CwzzlutHzs4xgZFW29kH6YsM2nT0MfQOjZCVR /y5a4TLI8nlFsb9QHZ64nVH6AFMjZQNhMugvmU0RKlSd2KQSH54FqkTptVkA= X-Sasl-enc: /fZAGEI85LHajfrPaEsnve8yffAHUu6EVy7FURfeeF5F 1437093599 Received: from sjc-alcoop-8818.cisco.com (unknown [128.107.241.179]) by mail.messagingengine.com (Postfix) with ESMTPA id E6041680157; Thu, 16 Jul 2015 20:39:58 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: Date: Thu, 16 Jul 2015 17:39:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> To: Randall Gellens X-Mailer: Apple Mail (2.1878.6) Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 00:40:02 -0000 Hi Randy, Thanks for your response. On Jul 9, 2015, at 6:47 PM, Randall Gellens = wrote: > At 3:19 PM -0700 7/9/15, Alissa Cooper wrote: >=20 >> Hi Randy, >>=20 >> Thanks for addressing my comments. I have one follow-up below. >=20 > Hi Alissa, >=20 > Thanks very much. Please see in-line. >=20 >> On Jun 28, 2015, at 6:53 PM, Randall Gellens=20 >> wrote: >>=20 >>>>=20 >>>> 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. >>>=20 >>> 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.=20 >>=20 >> How does the user make an emergency call without current service? >=20 > It varies by region; for example, in the U.S. and some European=20 > countries, telephone companies (cellular and wirelines) are required=20= > to provide emergency access (911 or 112) even if the device or=20 > landline has no service. So, old cell phones that haven't had=20 > service in years can still be used to dial 911 (or 112), and=20 > landlines that have been turned off for non-payment can usually still=20= > dial 911. The situation with landlines is a little different from=20 > cell phones, so there can be a completely dead landline that is=20 > unable to dial 911. PSAPs do get lots false calls from old cell=20 > phones that parents have given to kids as toys, for example. Or=20 > older kids who think it's funny. Ok >=20 >>> 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). >>=20 >> It would be helpful if the above explanation could be included in the = draft. >=20 > I have added this. >=20 >> Given the explanation above, does it really make sense for the=20 >> device to be providing this information in addition to the service=20 >> provider? That is, the device may have many possible device IDs=20 >> that it could include, but it may not know which ones the service=20 >> provider collects and correlates to specific users, so it won't=20 >> necessarily know which ones to provide. Given that all of these IDs=20= >> can be uniquely identifying in different contexts, providing=20 >> multiple IDs that won't get used seems like not the best idea. And=20 >> if the user is abusing the emergency call system, he won't include=20 >> these anyway. >=20 > An attacker won't include the information (or would include fake=20 > information), but a legitimate device that is used by someone playing=20= > pranks, or kids as a toy, or someone who does need help and is using=20= > a device without service and can't provide any other information,=20 > would include information, and in these cases, it's better if the=20 > device includes it, since it's not clear what the service provider=20 > knows or will provide. >=20 >> Are we sure that all of the device types specified actually get=20 >> used in this way by PSAPs? E.g., I was curious about whether=20 >> service providers track device RFIDs. >=20 > I'm not aware of this being common with consumer devices, but it=20 > could happen with specialized devices. Some text to justify the different identifiers would be good to add to = the draft. >=20 >>=20 >> I also think, as much as I dislike the subscriber privacy indicator=20= >> specified in 4.4.1, it should cover this data element as well,=20 >> particularly since this element can be inserted by the service=20 >> provider without the user knowing. >=20 > The thing about the subscriber privacy indicator is that it's up to=20 > local regulation what elements it covers and what it means. I don't=20= > think we can dictate that. Well, does it have to be in the owner/subscriber block? I thought that = implied that it was only relevant to the owner/subscriber data, but if = it could be interpreted more broadly then I=92m not sure it makes sense = to put it in that block. Thanks, Alissa >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > Whenever you find that you are on the side of the majority, > it is time to reform. --Mark Twain From nobody Fri Jul 17 06:24:02 2015 Return-Path: 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 0D0AC1B33C9 for ; Fri, 17 Jul 2015 06:24:01 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 uX3id1Bkiyyn for ; Fri, 17 Jul 2015 06:23:59 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 820FB1B33BF for ; Fri, 17 Jul 2015 06:23:59 -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=1437139440; x=1468675440; h=message-id:date:to:from:subject: content-transfer-encoding; bh=C/3oHu3zR659eKe6TM1InS/nolyo4/6myrcgdSlNq7s=; b=zPVr3408S+sDRzlYu+zjkt7hMrSgEhRiASiJoKnAFVnTAIoGdRI9sfeF BKp2VRF6QyNIMDhjMkGPhTlJrcjcXVASoMeca4P5B+k0D8bQDsYM9HCox UN1xD3dGgHXi0QqlTj+/Xx720Q65gBFoBObsPGHTzxN2Fu9udS6BvCfn7 I=; X-IronPort-AV: E=McAfee;i="5700,7163,7864"; a="128386617" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jul 2015 06:24:00 -0700 X-IronPort-AV: E=Sophos;i="5.15,496,1432623600"; d="scan'208";a="963530179" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jul 2015 06:23:58 -0700 Received: from Ironmsg04-R.qualcomm.com (ironmsg04-R.qualcomm.com [172.30.46.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t6HDNwhR015302; Fri, 17 Jul 2015 06:23:58 -0700 X-IronPort-AV: E=Sophos;i="5.15,496,1432623600"; d="scan'208";a="1016664929" X-ojodefuego: yes Received: from unknown (HELO [99.111.97.136]) ([10.64.226.181]) by Ironmsg04-R.qualcomm.com with ESMTP; 17 Jul 2015 06:23:57 -0700 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Fri, 17 Jul 2015 06:23:55 -0700 To: ecrit@ietf.org From: Randall Gellens 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-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Ecrit] Tuesday Lunch in Prague to discuss SLIM real-time & email (both) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 13:24:01 -0000 The concierge has made a reservation for us at=20 Caf=E9 imperial (5-6 min walk), which is 100%=20 non-smoking. The is room for a few more people to join us. Because this is not inside the hotel, I don't=20 know if there will be Wi-Fi and hence if it will=20 be possible for people to join remotely. The only=20 hotel restaurant open for lunch permits smoking=20 (although it's possible additional venues will be=20 opened). At 11:39 AM -0700 7/10/15, Randall Gellens wrote: > It seems that Tuesday lunch works for everyone=20 > interested in the SLIM real-time and email=20 > work, so let's settle on that for both. Please=20 > confirm your attendance to me today if=20 > possible, and if we have enough I will reserve=20 > a room at a restaurant in the hotel, so we can=20 > talk and be heard. If we can meet pretty=20 > quickly after the morning session ends, we can=20 > have time for both topics. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > I don't want to achieve immortality through my work.... > I want to achieve immortality by not dying.- > --Woody Allen -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- #Random Tag -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- This is what government looks like when it's entrusted to people who don't believe in government. --Barbara Roper of the Consumer Federation of America, commenting on the failure of oversight that made possible the Madoff scam. From nobody Fri Jul 17 08:59:40 2015 Return-Path: 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 034171A219E for ; Fri, 17 Jul 2015 08:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.368 X-Spam-Level: X-Spam-Status: No, score=-0.368 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 fRAXPCFzdO0f for ; Fri, 17 Jul 2015 08:59:38 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D321A21C1 for ; Fri, 17 Jul 2015 08:59:37 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.14.7) with SMTP id t6HFpULV026664; Fri, 17 Jul 2015 11:59:35 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1vq1asgjfv-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 17 Jul 2015 11:59:35 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.249]) by stntexhc10.cis.neustar.com ([169.254.4.214]) with mapi id 14.03.0158.001; Fri, 17 Jul 2015 11:59:34 -0400 From: "Rosen, Brian" To: Alissa Cooper Thread-Topic: [Ecrit] AD review: draft-ietf-ecrit-additional-data-29 Thread-Index: AQHQwKmS0omSWVw7Q0qgCuevcEoN5w== Date: Fri, 17 Jul 2015 15:59:34 +0000 Message-ID: <5903491F-5756-4D9A-BD7A-A81C75EF6730@neustar.biz> References: <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.17] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9F8527A993208B419E697ECD6B4C5076@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-17_08:2015-07-17,2015-07-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "ecrit@ietf.org" , Randall Gellens 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 15:59:39 -0000 >>=20 >> The thing about the subscriber privacy indicator is that it's up to=20 >> local regulation what elements it covers and what it means. I don't=20 >> think we can dictate that. >=20 > Well, does it have to be in the owner/subscriber block? I thought that im= plied that it was only relevant to the owner/subscriber data, but if it cou= ld be interpreted more broadly then I=92m not sure it makes sense to put it= in that block. >=20 There are jurisdictions that, for example, would consider the telephone num= ber to be private, and that is not in the owner/subscriber block. But all = of the data in that block is affected by the privacy indicator in all the j= urisdictions I=92m aware of. So, I do think it=92s in the right place. Randy=92s point was that what it means changes from one jurisdiction to ano= ther, so what fields it affects could vary, and which blocks they are a par= t of will vary. I don=92t think we want to make the mechanism more complex= .=20 Brian From nobody Sun Jul 19 02:50:29 2015 Return-Path: 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 7B82E1A9040 for ; Sun, 19 Jul 2015 02:50:28 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 yIc2tR-I2LeJ for ; Sun, 19 Jul 2015 02:50:26 -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 C881F1A8A78 for ; Sun, 19 Jul 2015 02:50:26 -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=1437299426; x=1468835426; h=message-id:in-reply-to:references:date:to:from:subject: cc; bh=dQ0X1tK8aG330o7sa5hJFgkMKGOfpy3mTbQ2kTyCNd8=; b=YRxRSlxm2IOHwSpipL7DyLctknmvekTZJNZ/bBCsPNGBg7chqtfHnWTI sVqDy6Yjzstp891NuJlxWzcLu4zv7YFO3pQuiCIa/44NaD27E+vueMsf7 IvsiYdvvcqi5v5vZ/uLuQpxuEEaDMAo0V1HC4nE7+qyDDtmyKHte4e0Te M=; X-IronPort-AV: E=McAfee;i="5700,7163,7866"; a="94148934" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2015 02:50:26 -0700 X-IronPort-AV: E=Sophos;i="5.15,502,1432623600"; d="scan'208";a="482116455" Received: from plus.qualcomm.com ([10.52.255.8]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2015 02:50:24 -0700 Received: from Ironmsg04-L.qualcomm.com (ironmsg04-L.qualcomm.com [172.30.48.19]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t6J9oN7O030237; Sun, 19 Jul 2015 02:50:23 -0700 X-IronPort-AV: E=Sophos;i="5.15,502,1432623600"; d="scan'208";a="938163075" X-ojodefuego: yes Received: from unknown (HELO [130.129.14.251]) ([10.64.229.15]) by Ironmsg04-L.qualcomm.com with ESMTP; 19 Jul 2015 02:49:57 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> X-Mailer: Eudora for Mac OS X Date: Sun, 19 Jul 2015 02:49:54 -0700 To: Alissa Cooper , Brian Rosen From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 09:50:28 -0000 Hi Alissa, At 5:39 PM -0700 7/16/15, Alissa Cooper wrote: > Hi Randy, > > Thanks for your response. > > On Jul 9, 2015, at 6:47 PM, Randall Gellens wrote: > >> At 3:19 PM -0700 7/9/15, Alissa Cooper wrote: >> >>> Hi Randy, >>> >>> Thanks for addressing my comments. I have one follow-up below. >> >> Hi Alissa, >> >> Thanks very much. Please see in-line. >> >>> On Jun 28, 2015, at 6:53 PM, Randall Gellens >>> wrote: >>> >>>>> >>>>> 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. >>> >>> How does the user make an emergency call without current service? >> >> It varies by region; for example, in the U.S. and some European >> countries, telephone companies (cellular and wirelines) are required >> to provide emergency access (911 or 112) even if the device or >> landline has no service. So, old cell phones that haven't had >> service in years can still be used to dial 911 (or 112), and >> landlines that have been turned off for non-payment can usually still >> dial 911. The situation with landlines is a little different from >> cell phones, so there can be a completely dead landline that is >> unable to dial 911. PSAPs do get lots false calls from old cell >> phones that parents have given to kids as toys, for example. Or >> older kids who think it's funny. > > Ok > >> >>>> 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). >>> >>> It would be helpful if the above explanation could be included in >>> the draft. >> >> I have added this. >> >>> Given the explanation above, does it really make sense for the >>> device to be providing this information in addition to the service >>> provider? That is, the device may have many possible device IDs >>> that it could include, but it may not know which ones the service >>> provider collects and correlates to specific users, so it won't >>> necessarily know which ones to provide. Given that all of these IDs >>> can be uniquely identifying in different contexts, providing >>> multiple IDs that won't get used seems like not the best idea. And >>> if the user is abusing the emergency call system, he won't include >>> these anyway. >> >> An attacker won't include the information (or would include fake >> information), but a legitimate device that is used by someone playing >> pranks, or kids as a toy, or someone who does need help and is using >> a device without service and can't provide any other information, >> would include information, and in these cases, it's better if the >> device includes it, since it's not clear what the service provider >> knows or will provide. >> >>> Are we sure that all of the device types specified actually get >>> used in this way by PSAPs? E.g., I was curious about whether >>> service providers track device RFIDs. >> >> I'm not aware of this being common with consumer devices, but it >> could happen with specialized devices. > > Some text to justify the different identifiers would be good to add > to the draft. I'm not really sure what text would be helpful. > >> >>> >>> I also think, as much as I dislike the subscriber privacy indicator >>> specified in 4.4.1, it should cover this data element as well, > >> particularly since this element can be inserted by the service >>> provider without the user knowing. >> >> The thing about the subscriber privacy indicator is that it's up to >> local regulation what elements it covers and what it means. I don't >> think we can dictate that. > > Well, does it have to be in the owner/subscriber block? I thought > that implied that it was only relevant to the owner/subscriber > data, but if it could be interpreted more broadly then I'm not sure > it makes sense to put it in that block. Brian addressed this in his reply; there really isn't a better place and I don't see it being harmful to leave it where it is. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Twenty-five per cent of the passengers of almost any aircraft show white knuckles on take-off. --Colin Marshall, CEO British Airways. From nobody Sun Jul 19 02:53:16 2015 Return-Path: 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 13EB21AC3EA for ; Sun, 19 Jul 2015 02:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 eamaD7cMB5nr for ; Sun, 19 Jul 2015 02:53:15 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1746A1AC3D7 for ; Sun, 19 Jul 2015 02:53:15 -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=1437299595; x=1468835595; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=BYiDdEzTJnzGSGNINp4Iu+GIIhF+vDr2LPwrSPFTLNw=; b=zBIHVCktEiBwHbTKIgHtcssN0sTwLofic4oH876N6dhpjB79jh4+csuU wnNmemRlPt6z1+O0d1pKe03edCUy6dpaLSY+tYzEIp0kCmNuR+P8nBkqW CtNPt8iWYFiCal+oer4M1GF0vaYprpmrSgP6VKBAan1a+E01TAgk8Tbd5 I=; X-IronPort-AV: E=McAfee;i="5700,7163,7866"; a="93057389" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2015 02:53:03 -0700 X-IronPort-AV: E=Sophos;i="5.15,502,1432623600"; d="scan'208";a="938165143" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Jul 2015 02:53:03 -0700 Received: from [130.129.14.251] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sun, 19 Jul 2015 02:53:01 -0700 Message-ID: In-Reply-To: <9101d605033c44db863e009c4893d4b5@DAGN04C-S1E7.exg7.exghost.local> References: <9101d605033c44db863e009c4893d4b5@DAGN04C-S1E7.exg7.exghost.local> X-Mailer: Eudora for Mac OS X Date: Sun, 19 Jul 2015 02:52:56 -0700 To: Matt Serra , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Subject: Re: [Ecrit] Comments on draft-ietf-ecrit-additional-data-32 / Data Provider String Usage X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 09:53:16 -0000 At 6:00 PM +0000 7/10/15, Matt Serra wrote: > An observation on the latest draft: > > Section 4.1.1 Data Provider String: The Usage is documented as > "Conditional", yet the condition is not clearly specified - this > may have been muddled when we added guidance for how this field is > populated by Devices. > > I suggest we change the Usage to Required, or minimally Optional. I added the same text that appears for the other strings (such as Data Provider ID): "Optional for blocks supplied by the originating device, mandatory otherwise". -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Prostitutes Appeal to Pope --Newspaper headline From nobody Sun Jul 19 03:20:34 2015 Return-Path: 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 A3B391A8AC0 for ; Sun, 19 Jul 2015 03:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 ZO32R0THmmDV for ; Sun, 19 Jul 2015 03:20:31 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46F5F1A8ABD for ; Sun, 19 Jul 2015 03:20:31 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9B585202D4 for ; Sun, 19 Jul 2015 06:20:30 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Sun, 19 Jul 2015 06:20:30 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=CSIp5gOY3nyjNMJzDhN52G8yJMg=; b=jqZYb1 Wj0RNzEsRK0OqnDRBX3YVX2vXJ1OuaHX3o61yiKFyWcnuQ94QeOzEjMosubPPQng 65WSyTAICE6OpOrLRZmmgSTaRkanzqgYoVsmTD9KAxU3D1DyhWFPKTmCsgHrIfr2 uS+BzwYwg0GpfqtA2mdBsSebeN/myqV8nk4Wk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=CSIp5gOY3nyjNMJ zDhN52G8yJMg=; b=hZ8O4bfN1Guvjodnb+b39o2yPXJ+XdiH6rNGg3RGFdm/Vb4 O9cTD20jXVPSwc0ktvqlLn47iSf66DJMAPKZEmF0zEhAR0Hj35ZAVNVuHYQCVTMA AHV/muqEw01KGWby8uwTqGL7ue7QZDk8yxFljC+sE4JDA+aaGSZHHUKQl9bI= X-Sasl-enc: OLcLbmZh/6KyzQxwH7jinGq/PiO7tIwIBEBoFnIhSzP0 1437301229 Received: from [10.24.134.123] (unknown [128.107.241.162]) by mail.messagingengine.com (Postfix) with ESMTPA id D4124C00017; Sun, 19 Jul 2015 06:20:27 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <5903491F-5756-4D9A-BD7A-A81C75EF6730@neustar.biz> Date: Sun, 19 Jul 2015 12:20:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> <5903491F-5756-4D9A-BD7A-A81C75EF6730@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "ecrit@ietf.org" , Randall Gellens 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 10:20:32 -0000 On Jul 17, 2015, at 5:59 PM, Rosen, Brian = wrote: >>>=20 >>> The thing about the subscriber privacy indicator is that it's up to=20= >>> local regulation what elements it covers and what it means. I don't=20= >>> think we can dictate that. >>=20 >> Well, does it have to be in the owner/subscriber block? I thought = that implied that it was only relevant to the owner/subscriber data, but = if it could be interpreted more broadly then I=92m not sure it makes = sense to put it in that block. >>=20 > There are jurisdictions that, for example, would consider the = telephone number to be private, and that is not in the owner/subscriber = block. But all of the data in that block is affected by the privacy = indicator in all the jurisdictions I=92m aware of. So, I do think it=92s = in the right place. >=20 > Randy=92s point was that what it means changes from one jurisdiction = to another, so what fields it affects could vary, and which blocks they = are a part of will vary. I don=92t think we want to make the mechanism = more complex.=20 Ok. If you could add a sentence to the description to make it clear that = the application of the indicator may extend to any of the additional = data shared, I think that would help. Thanks, Alissa >=20 > Brian >=20 >=20 From nobody Sun Jul 19 03:23:43 2015 Return-Path: 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 401F81A8AC0 for ; Sun, 19 Jul 2015 03:23:42 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 pdShjV1LgPqF for ; Sun, 19 Jul 2015 03:23:40 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEB5E1A8ABD for ; Sun, 19 Jul 2015 03:23:40 -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=1437301420; x=1468837420; h=message-id:in-reply-to:references:date:to:from:subject; bh=FVf5FAdcvReiPknf1BdoNUx9iZIPh9B1RkIJ63ne3pY=; b=zTQRimuoPkBoS6Zm5yM1ugFr2g/Ef4TpzplEN6dQdyMJOoDsni1lIXsk bdCE9MwQIIc547xI2ExKZ5kXPv90X5nlgHPeY0kZN/dP9LUF9mtZDhd93 Yen9O4mCwQ8sBatd9g1iF7F/fgFGa+L68tjgGP8dfNZwJRcP6J0j3V3ty Y=; X-IronPort-AV: E=McAfee;i="5700,7163,7866"; a="128608868" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2015 03:23:40 -0700 X-IronPort-AV: E=Sophos;i="5.15,502,1432623600"; d="scan'208";a="964715915" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2015 03:23:40 -0700 Received: from Ironmsg04-R.qualcomm.com (ironmsg04-R.qualcomm.com [172.30.46.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t6JANdpD001137; Sun, 19 Jul 2015 03:23:40 -0700 X-IronPort-AV: E=Sophos;i="5.15,502,1432623600"; d="scan'208";a="1017927278" X-ojodefuego: yes Received: from unknown (HELO [130.129.14.251]) ([10.64.229.15]) by Ironmsg04-R.qualcomm.com with ESMTP; 19 Jul 2015 03:23:34 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <9e52f2a2f2d54c0c97257a444a61559e@DAGN04C-S1E7.exg7.exghost.local> References: <9e52f2a2f2d54c0c97257a444a61559e@DAGN04C-S1E7.exg7.exghost.local> X-Mailer: Eudora for Mac OS X Date: Sun, 19 Jul 2015 03:23:32 -0700 To: Matt Serra , "ecrit@ietf.org" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Ecrit] Comments on draft-ietf-ecrit-additional-data-32 / "Data About" registry X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 10:23:42 -0000 At 8:58 PM +0000 7/10/15, Matt Serra wrote: > Randall & WG: > > The NENA Add'l Data WG reviewed some of the recent changes (through > v32) this past Monday. > > We have two comments (and a NIT) on the recently added Emergency > Call Data Types Registry (section 10.1.9) > > 1. To support future growth, we suggest the "Data About" field > support multiple values per token. As defined here, only one value > per token is allowed. This does not support cases where a Token > could be used to communicate more than one form of data, but less > than "All" forms of data. Here is the current text. Proposed > changes _from_ this: > > " The value MUST be _either_ "The Call", "The Caller", "The > Location", or "All". New values are created by extending this > registry in a subsequent RFC." > > _To_ this: > > " The value MUST be _one or more of_ "The Call", "The Caller", "The > Location". New values are created by extending this registry in a > subsequent RFC." This field is merely a hint to help guide PSAPs or other entities in deciding if they wish to access a block or not; they need to consider the block's contents, not just this field. This is why the field only exists in the registry, and is not contained within the block. So, I'm not sure that's it's helpful to try and make this field too precise. I changed the "All" to "Multiple" to indicate that the block can be considered as applying to more than one category, and I added clarifying text that explains that this is merely a hint and not contained in the block. Does this seem OK? > > 2. Our group was a confused by what affect the values in this > registry have on the XML, noting the text describing "Data About" > can be interpreted to imply Data About is passed in the XML so it > can be inspected by the PSAP: "Indicates if the data describes the > call, the caller, or the location (or is applicable to all), which > helps PSAPs and other entities determine if they wish to process > the block." > > Additionally, please consider changing the _following text_ for clarity: > > "Note that the _values_ from this registry are part of the > 'EmergencyCallData' compound value; when used as a value of the > 'purpose' parameter of the Call-Info header, the _values_ listed in > this registry are prefixed by 'EmergencyCallData.' per _the the_ > 'EmergencyCallData' registration" > > To this: > > "Note that the _tokens_ from this registry are part of the > 'EmergencyCallData' compound value; when used as a value of the > 'purpose' parameter of the Call-Info header, the _tokens_ listed in > this registry are prefixed by 'EmergencyCallData.' per _the_ > 'EmergencyCallData' registration" OK > > Finally, a NIT: you will see the last phrase if the above passage > repeats the word "the" Thanks. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Politics is the art of making the inevitable appear to be a matter of wise human choice. --Quentin Crisp From nobody Sun Jul 19 07:53:47 2015 Return-Path: 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 52DCC1AD356 for ; Sun, 19 Jul 2015 07:53:45 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 vRKrmjN0YYq3 for ; Sun, 19 Jul 2015 07:53:44 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F2E1AD351 for ; Sun, 19 Jul 2015 07:53:44 -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=1437317624; x=1468853624; h=message-id:in-reply-to:references:date:to:from:subject: cc; bh=zRNDmqyyL681laPNbe4T4lg5RKtaIC4oDsU+owazkKw=; b=YKYtPB/W1dCyt1KMBUr4uOPUwu92PiOEUBrlCtuoPxD2rQq/WjJ9cwho FLFXQxHeh/MiTYPeoMmi7xWjPoDrrCbREDhfNSc3rQFXM/twH6Fv45xho bF6QN4y5rpX59f5HhqAKnNjq1oCoX5AqFogNbW+UoOGkpkzo9Vmyu5sXy I=; X-IronPort-AV: E=McAfee;i="5700,7163,7866"; a="128622110" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2015 07:53:43 -0700 X-IronPort-AV: E=Sophos;i="5.15,503,1432623600"; d="scan'208";a="963744690" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2015 07:53:43 -0700 Received: from Ironmsg03-L.qualcomm.com (ironmsg03-L.qualcomm.com [172.30.48.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t6JErgnl029623; Sun, 19 Jul 2015 07:53:43 -0700 X-IronPort-AV: E=Sophos;i="5.15,503,1432623600"; d="scan'208";a="963744678" X-ojodefuego: yes Received: from unknown (HELO [130.129.14.251]) ([10.64.229.15]) by Ironmsg03-L.qualcomm.com with ESMTP; 19 Jul 2015 07:53:40 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> <5903491F-5756-4D9A-BD7A-A81C75EF6730@neustar.biz> X-Mailer: Eudora for Mac OS X Date: Sun, 19 Jul 2015 07:53:38 -0700 To: Alissa Cooper , "Rosen, Brian" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 14:53:45 -0000 At 12:20 PM +0200 7/19/15, Alissa Cooper wrote: > On Jul 17, 2015, at 5:59 PM, Rosen, Brian wrote: > >>>> >>>> The thing about the subscriber privacy indicator is that it's up to >>>> local regulation what elements it covers and what it means. I don't >>>> think we can dictate that. >>> >>> Well, does it have to be in the owner/subscriber block? I thought >>> that implied that it was only relevant to the owner/subscriber >>> data, but if it could be interpreted more broadly then I'm not >>> sure it makes sense to put it in that block. >>> >> There are jurisdictions that, for example, would consider the >> telephone number to be private, and that is not in the >> owner/subscriber block. But all of the data in that block is >> affected by the privacy indicator in all the jurisdictions I'm >> aware of. So, I do think it's in the right place. >> >> Randy's point was that what it means changes from one jurisdiction >> to another, so what fields it affects could vary, and which blocks >> they are a part of will vary. I don't think we want to make the >> mechanism more complex. > > Ok. If you could add a sentence to the description to make it clear > that the application of the indicator may extend to any of the > additional data shared, I think that would help. Happy to. I added: Because the interpretation of this indicator varies based on local regulations, this document cannot describe the exact semantics nor indicate which fields are affected (the application of this indicator might affect the display of data contained in any of the blocks). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- It is much easier to suggest solutions when you know nothing about the problem. From nobody Mon Jul 20 10:34:14 2015 Return-Path: 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 F18371B2D0C for ; Mon, 20 Jul 2015 10:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 jmkOUuCsxsTi for ; Mon, 20 Jul 2015 10:34:00 -0700 (PDT) Received: from server907.appriver.com (server907e.appriver.com [204.232.250.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB33F1B2D29 for ; Mon, 20 Jul 2015 10:33:59 -0700 (PDT) X-Note-AR-ScanTimeLocal: 7/20/2015 1:33:56 PM X-Policy: GLOBAL - UNKNOWN X-Policy: GLOBAL - UNKNOWN X-Primary: mserra@ravemobilesafety.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 7/6/2015 7:53:48 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-158/SG:2 7/20/2015 1:33:12 PM X-GBUdb-Analysis: 0, 10.246.0.39, Ugly c=1 p=-0.982189 Source White X-Signature-Violations: 0-0-0-9301-c X-Note-419: 31.2587 ms. Fail:0 Chk:1327 of 1327 total X-Note: SCH-CT/SI:0-1327/SG:1 7/20/2015 1:33:53 PM X-Note: Spam Tests Failed: X-Country-Path: ->->PRIVATE-> X-Note-Sending-IP: 10.246.0.39 X-Note-Reverse-DNS: X-Note-Return-Path: mserra@ravemobilesafety.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G256 G257 G258 G259 G263 G264 G383 G400 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [10.246.0.39] (HELO smtp.us.exg7.exghost.com) by server907.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 13375100; Mon, 20 Jul 2015 13:33:56 -0400 Received: from DAGN04C-S1E7.exg7.exghost.local (192.168.244.55) by DAGN04C-S1E7.exg7.exghost.local (192.168.244.55) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 20 Jul 2015 13:33:56 -0400 Received: from DAGN04C-S1E7.exg7.exghost.local ([fe80::4cb2:4e3d:f0de:b4ed]) by DAGN04C-S1E7.exg7.exghost.local ([fe80::4cb2:4e3d:f0de:b4ed%22]) with mapi id 15.00.1104.000; Mon, 20 Jul 2015 13:33:56 -0400 From: Matt Serra To: Randall Gellens , "ecrit@ietf.org" Thread-Topic: [Ecrit] Comments on draft-ietf-ecrit-additional-data-32 / "Data About" registry Thread-Index: AQHQwgz8Gtki7LVlEUy7xa3FSfJkkJ3knjMw Date: Mon, 20 Jul 2015 17:33:56 +0000 Message-ID: <1121db0ace6145f4881a276b9fa86570@DAGN04C-S1E7.exg7.exghost.local> References: <9e52f2a2f2d54c0c97257a444a61559e@DAGN04C-S1E7.exg7.exghost.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.244.1] x-exclaimer-md-config: 952e3d35-ca29-4b9e-94e1-a56fe70f6560 x-rerouted-by-exchange: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] Comments on draft-ietf-ecrit-additional-data-32 / "Data About" registry X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 17:34:05 -0000 Randall: I do think "multiple" is a step in the right direction, and given the scope= of the current document, will work. If we to this registry in a way that = injects more ambiguity, I think we should revisit allowing for more than on= e value in the "Data About" field, even if just comma delimited. Thanks for accepting in the other comments in this email, plus the comment = about the "Data Provider String" usage sent under separate cover. Can I as= sume we'll see those edits in a version '33'? Regards, Matt. -----Original Message----- From: Randall Gellens [mailto:rg+ietf@qti.qualcomm.com]=20 Sent: Sunday, July 19, 2015 6:24 AM To: Matt Serra; ecrit@ietf.org Subject: Re: [Ecrit] Comments on draft-ietf-ecrit-additional-data-32 / "Dat= a About" registry At 8:58 PM +0000 7/10/15, Matt Serra wrote: > Randall & WG: > > The NENA Add'l Data WG reviewed some of the recent changes (through > v32) this past Monday. > > We have two comments (and a NIT) on the recently added Emergency=20 > Call Data Types Registry (section 10.1.9) > > 1. To support future growth, we suggest the "Data About" field=20 > support multiple values per token. As defined here, only one value=20 > per token is allowed. This does not support cases where a Token could=20 > be used to communicate more than one form of data, but less than "All"=20 > forms of data. Here is the current text. Proposed changes _from_=20 > this: > > " The value MUST be _either_ "The Call", "The Caller", "The=20 > Location", or "All". New values are created by extending this=20 > registry in a subsequent RFC." > > _To_ this: > > " The value MUST be _one or more of_ "The Call", "The Caller", "The=20 > Location". New values are created by extending this registry in a=20 > subsequent RFC." This field is merely a hint to help guide PSAPs or other entities in decidi= ng if they wish to access a block or not; they need to consider the block's= contents, not just this field. This is why the field only exists in the r= egistry, and is not contained within the block.=20 So, I'm not sure that's it's helpful to try and make this field too precise= . I changed the "All" to "Multiple" to indicate that the block can be conside= red as applying to more than one category, and I added clarifying text that= explains that this is merely a hint and not contained in the block. Does = this seem OK? > > 2. Our group was a confused by what affect the values in this=20 > registry have on the XML, noting the text describing "Data About" > can be interpreted to imply Data About is passed in the XML so it can=20 > be inspected by the PSAP: "Indicates if the data describes the call,=20 > the caller, or the location (or is applicable to all), which helps=20 > PSAPs and other entities determine if they wish to process the block." > > Additionally, please consider changing the _following text_ for clarity: > > "Note that the _values_ from this registry are part of the=20 > 'EmergencyCallData' compound value; when used as a value of the=20 > 'purpose' parameter of the Call-Info header, the _values_ listed in=20 > this registry are prefixed by 'EmergencyCallData.' per _the the_=20 > 'EmergencyCallData' registration" > > To this: > > "Note that the _tokens_ from this registry are part of the=20 > 'EmergencyCallData' compound value; when used as a value of the=20 > 'purpose' parameter of the Call-Info header, the _tokens_ listed in=20 > this registry are prefixed by 'EmergencyCallData.' per _the_=20 > 'EmergencyCallData' registration" OK > > Finally, a NIT: you will see the last phrase if the above passage=20 > repeats the word "the" Thanks. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Politics is the art o= f making the inevitable appear to be a matter of wise human choice. --Quentin Crisp From nobody Mon Jul 20 11:05:07 2015 Return-Path: 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 B55331B2A71 for ; Mon, 20 Jul 2015 11:05:01 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 q0eicQrke_Qk for ; Mon, 20 Jul 2015 11:04:55 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E741B2A62 for ; Mon, 20 Jul 2015 11:04:52 -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=1437415492; x=1468951492; h=message-id:in-reply-to:references:date:to:from:subject: content-transfer-encoding; bh=GG9K8c/ecwVSfU8vmZ4Gn++0GbV4qEz+bHcWBXwdDdg=; b=bPI3CzLk6PM8SsgPv2682TK1bgMoWHvjPbEoLrikFfWvzOtoMT8xvsSF xld7Z1OsWMVPfePShSBVhQbStmW070tWVVKEx7cksjuSFUxRDDvRQsmtq eLrBzcqnItvOqQOHWJuP2nbmrQHhp211dL0rOGZVWQMHf406I9e9nERPR s=; X-IronPort-AV: E=McAfee;i="5700,7163,7867"; a="128773069" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2015 11:04:52 -0700 X-IronPort-AV: E=Sophos;i="5.15,509,1432623600"; d="scan'208";a="516096479" Received: from plus.qualcomm.com ([10.52.255.8]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2015 11:04:13 -0700 Received: from Ironmsg03-R.qualcomm.com (ironmsg03-R.qualcomm.com [172.30.46.17]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t6KI48FJ002222; Mon, 20 Jul 2015 11:04:12 -0700 X-IronPort-AV: E=Sophos;i="5.15,509,1432623600"; d="scan'208";a="965551364" X-ojodefuego: yes Received: from unknown (HELO [130.129.14.251]) ([10.64.225.35]) by Ironmsg03-R.qualcomm.com with ESMTP; 20 Jul 2015 11:04:05 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Mon, 20 Jul 2015 09:15:34 -0700 To: ecrit@ietf.org From: Randall Gellens 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-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: Subject: Re: [Ecrit] Tuesday Lunch in Prague to discuss SLIM real-time & email (both) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 18:05:01 -0000 To get to Caf=E9 Imperial, exit the hotel lobby,=20 turn left to follow the driveway down to the=20 street, cross the street and continue. At the=20 next street, which is a fairly big street with=20 streetcars, turn right, walk under the underpass,=20 and keep going. The restaurant is two blocks=20 down on the right. https://www.google.cz/maps/dir/Hilton+Prague+Hotel,+Pob%C5%99e%C5%BEn%C3%AD+= 1,+186+00+Praha+8/Caf%C3%A9+Imperial,+Na+Po%C5%99%C3%AD%C4%8D%C3%AD+15,+110+= 00+Praha+1/@50.0915465,14.4319304,16z/data=3D!3m1!4b1!4m13!4m12!1m5!1m1!1s0x= 470b94bebc825d65:0x3c034881ea713b97!2m2!1d14.439794!2d50.093322!1m5!1m1!1s0x= 470b949558c1bf45:0x9fea082416e2f3e9!2m2!1d14.4328883!2d50.0899095 At 6:23 AM -0700 7/17/15, Randall Gellens wrote: > The concierge has made a reservation for us at=20 > Caf=E9 imperial (5-6 min walk), which is 100%=20 > non-smoking. > > The is room for a few more people to join us. > > Because this is not inside the hotel, I don't=20 > know if there will be Wi-Fi and hence if it=20 > will be possible for people to join remotely.=20 > The only hotel restaurant open for lunch=20 > permits smoking (although it's possible=20 > additional venues will be opened). > > At 11:39 AM -0700 7/10/15, Randall Gellens wrote: > >> It seems that Tuesday lunch works for=20 >> everyone interested in the SLIM real-time and=20 >> email work, so let's settle on that for both.=20 >> Please confirm your attendance to me today if=20 >> possible, and if we have enough I will reserve=20 >> a room at a restaurant in the hotel, so we can=20 >> talk and be heard. If we can meet pretty=20 >> quickly after the morning session ends, we can=20 >> have time for both topics. >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself onl= y >> -------------- Randomly selected tag: --------------- >> I don't want to achieve immortality through my work.... >> I want to achieve immortality by not dying.- >> --Woody Allen > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > #Random Tag > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > This is what government looks like when it's entrusted > to people who don't believe in government. > --Barbara Roper of the Consumer Federation of America, > commenting on the failure of oversight that made possible > the Madoff scam. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- One seldom sees a monument to a committee. From nobody Mon Jul 20 13:12:45 2015 Return-Path: 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 B5E741B2BCC for ; Mon, 20 Jul 2015 13:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 Ixco5Jx_IwTS for ; Mon, 20 Jul 2015 13:12:43 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFFAC1A0091 for ; Mon, 20 Jul 2015 13:12:42 -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=1437423162; x=1468959162; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=Dcj1kE6W1iAzaQgDA8f4NbO/DMohLLoqUBP69H0MoPg=; b=jwGIN4SIAahc10jh9LOC7ViC7fsx9TN5oJ8+og8WMEqLFxmLKGZ5WybU joncEJwPzD3+pgv2L+nTcOBR8dfL11uye6t8MV0U9ClU9aAuDvzqXUb4M 4G6XqUHmQeIEvQURj9OxCa4LELHjXg4PuIH/HBYfsWKgmoEX2q1BR618x g=; X-IronPort-AV: E=McAfee;i="5700,7163,7868"; a="128787027" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2015 13:12:42 -0700 X-IronPort-AV: E=Sophos;i="5.15,509,1432623600"; d="scan'208";a="964518330" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Jul 2015 13:12:42 -0700 Received: from [130.129.14.251] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 20 Jul 2015 13:12:39 -0700 Message-ID: In-Reply-To: <1121db0ace6145f4881a276b9fa86570@DAGN04C-S1E7.exg7.exghost.local> References: <9e52f2a2f2d54c0c97257a444a61559e@DAGN04C-S1E7.exg7.exghost.local> <1121db0ace6145f4881a276b9fa86570@DAGN04C-S1E7.exg7.exghost.local> X-Mailer: Eudora for Mac OS X Date: Mon, 20 Jul 2015 13:12:35 -0700 To: Matt Serra , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Subject: Re: [Ecrit] Comments on draft-ietf-ecrit-additional-data-32 / "Data About" registry X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 20:12:44 -0000 Hi Matt, I'm submitting -33 now, it should appear within the hour. It has these edits. At 5:33 PM +0000 7/20/15, Matt Serra wrote: > Randall: > > I do think "multiple" is a step in the right direction, and given > the scope of the current document, will work. If we to this > registry in a way that injects more ambiguity, I think we should > revisit allowing for more than one value in the "Data About" field, > even if just comma delimited. > > Thanks for accepting in the other comments in this email, plus the > comment about the "Data Provider String" usage sent under separate > cover. Can I assume we'll see those edits in a version '33'? > > Regards, > > Matt. > > -----Original Message----- > From: Randall Gellens [mailto:rg+ietf@qti.qualcomm.com] > Sent: Sunday, July 19, 2015 6:24 AM > To: Matt Serra; ecrit@ietf.org > Subject: Re: [Ecrit] Comments on > draft-ietf-ecrit-additional-data-32 / "Data About" registry > > At 8:58 PM +0000 7/10/15, Matt Serra wrote: > >> Randall & WG: >> >> The NENA Add'l Data WG reviewed some of the recent changes (through >> v32) this past Monday. >> >> We have two comments (and a NIT) on the recently added Emergency >> Call Data Types Registry (section 10.1.9) >> >> 1. To support future growth, we suggest the "Data About" field >> support multiple values per token. As defined here, only one value >> per token is allowed. This does not support cases where a Token could >> be used to communicate more than one form of data, but less than "All" >> forms of data. Here is the current text. Proposed changes _from_ >> this: >> >> " The value MUST be _either_ "The Call", "The Caller", "The >> Location", or "All". New values are created by extending this >> registry in a subsequent RFC." >> >> _To_ this: >> >> " The value MUST be _one or more of_ "The Call", "The Caller", "The >> Location". New values are created by extending this registry in a >> subsequent RFC." > > This field is merely a hint to help guide PSAPs or other entities > in deciding if they wish to access a block or not; they need to > consider the block's contents, not just this field. This is why > the field only exists in the registry, and is not contained within > the block. > So, I'm not sure that's it's helpful to try and make this field too precise. > > I changed the "All" to "Multiple" to indicate that the block can be > considered as applying to more than one category, and I added > clarifying text that explains that this is merely a hint and not > contained in the block. Does this seem OK? > >> >> 2. Our group was a confused by what affect the values in this >> registry have on the XML, noting the text describing "Data About" >> can be interpreted to imply Data About is passed in the XML so it can >> be inspected by the PSAP: "Indicates if the data describes the call, >> the caller, or the location (or is applicable to all), which helps >> PSAPs and other entities determine if they wish to process the block." >> >> Additionally, please consider changing the _following text_ for clarity: >> >> "Note that the _values_ from this registry are part of the >> 'EmergencyCallData' compound value; when used as a value of the >> 'purpose' parameter of the Call-Info header, the _values_ listed in >> this registry are prefixed by 'EmergencyCallData.' per _the the_ >> 'EmergencyCallData' registration" >> >> To this: >> >> "Note that the _tokens_ from this registry are part of the >> 'EmergencyCallData' compound value; when used as a value of the >> 'purpose' parameter of the Call-Info header, the _tokens_ listed in >> this registry are prefixed by 'EmergencyCallData.' per _the_ >> 'EmergencyCallData' registration" > > OK > >> >> Finally, a NIT: you will see the last phrase if the above passage >> repeats the word "the" > > Thanks. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- Politics is > the art of making the inevitable appear to be a > matter of wise human choice. --Quentin Crisp > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Einstein never accepted quantum mechanics because of this element of chance and uncertainty. He said, "God does not play dice." It seems that Einstein was doubly wrong. The quantum effects of black holes suggests that not only does God play dice, He sometimes throws them where they cannot be seen. --Steven Hawking From nobody Mon Jul 20 13:15:22 2015 Return-Path: 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 4FDCF1B316A; Mon, 20 Jul 2015 13:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 X3umee73SR4A; Mon, 20 Jul 2015 13:15:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 033941B2BCC; Mon, 20 Jul 2015 13:15:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150720201517.18896.70463.idtracker@ietfa.amsl.com> Date: Mon, 20 Jul 2015 13:15:17 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-33.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 20:15:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Additional Data Related to an Emergency Call Authors : Randall Gellens Brian Rosen Hannes Tschofenig Roger Marshall James Winterbottom Filename : draft-ietf-ecrit-additional-data-33.txt Pages : 110 Date : 2015-07-20 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller or the location which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry the information described here using the mechanisms described here. The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-additional-data-33 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-33 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 21 00:00:14 2015 Return-Path: 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 2709A1AD0B2; Tue, 21 Jul 2015 00:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 8hkdgwq1Yi7S; Tue, 21 Jul 2015 00:00:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 072F01AD0B1; Tue, 21 Jul 2015 00:00:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150721070011.15298.16842.idtracker@ietfa.amsl.com> Date: Tue, 21 Jul 2015 00:00:11 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-held-routing-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 07:00:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : A Routing Request Extension for the HELD Protocol Authors : James Winterbottom Hannes Tschofenig Laura Liess Filename : draft-ietf-ecrit-held-routing-03.txt Pages : 14 Date : 2015-07-20 Abstract: For cases where location servers have access to emergency routing information they are able to return routing information with the location information if the location request includes a request for the desired routing information. This document specifies an extension to the HELD protocol to support this funciton. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-held-routing/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-held-routing-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-held-routing-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 21 00:01:17 2015 Return-Path: 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 4513C1AD0B3 for ; Tue, 21 Jul 2015 00:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 XKenn6myQJLL for ; Tue, 21 Jul 2015 00:01:13 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636D01AD0B1 for ; Tue, 21 Jul 2015 00:01:13 -0700 (PDT) Received: by pabkd10 with SMTP id kd10so42303351pab.2 for ; Tue, 21 Jul 2015 00:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=qMTHTd0vzQRSk6UJIxEB+1yR3Vpi65QVcq7S0RcJ6Eo=; b=YWx3VybzbWU6z5SlZtoqBdu1vGIxdETfjY+vqNGKMybiQTnQEpUSvOZqY0/tR0wN2D tRbx2FqyHnct4L+4XDLgHWIvaG6tjSwOELuw/T+rTAfYC5N4/E5mJy5G3wFGVcVAuP2P hPyn2YgnRaxqcIqpEVCzX0rnmBi5og5NuEFjKWYa5elHm8s/n9z4k4T72gJGbuF5tRez KO9870enXrCiIxxjZ10eZKupniIo7k433UPctLyPSyaBNDitC+1P5HyUPvACITxxz+/U UhZh6/YiZYpsSf4TI/8VyIzd0Z0TmhyyrRXFTDBEbcFO2DGS3a/ZSTODGPI6FKzjhFob SpCQ== X-Received: by 10.66.62.163 with SMTP id z3mr68944040par.12.1437462072986; Tue, 21 Jul 2015 00:01:12 -0700 (PDT) Received: from [192.168.1.11] (124-168-131-205.dyn.iinet.net.au. [124.168.131.205]) by smtp.gmail.com with ESMTPSA id by13sm25451755pdb.37.2015.07.21.00.01.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Jul 2015 00:01:12 -0700 (PDT) From: James Winterbottom Content-Type: multipart/alternative; boundary="Apple-Mail=_E8FA0C2B-3072-4C8A-93EB-212C1AC19303" Date: Tue, 21 Jul 2015 17:01:09 +1000 References: <20150721070011.15298.67689.idtracker@ietfa.amsl.com> To: "ecrit_ietf.org" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [Ecrit] Fwd: New Version Notification for draft-ietf-ecrit-held-routing-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 07:01:15 -0000 --Apple-Mail=_E8FA0C2B-3072-4C8A-93EB-212C1AC19303 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This version of the draft addresses the comments that Keith posted to = the list during WGLC. Cheers James > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-ecrit-held-routing-03.txt > Date: 21 July 2015 5:00:11 pm AEST > To: "Laura Liess" , "James Winterbottom" = , "Hannes Tschofenig" = , "Laura Liess" , "Hannes = Tschofenig" , "James Winterbottom" = >=20 >=20 > A new version of I-D, draft-ietf-ecrit-held-routing-03.txt > has been successfully submitted by James Winterbottom and posted to = the > IETF repository. >=20 > Name: draft-ietf-ecrit-held-routing > Revision: 03 > Title: A Routing Request Extension for the HELD = Protocol > Document date: 2015-07-20 > Group: ecrit > Pages: 14 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-ecrit-held-routing-03.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-ecrit-held-routing/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-ecrit-held-routing-03 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-held-routing-03 >=20 > Abstract: > For cases where location servers have access to emergency routing > information they are able to return routing information with the > location information if the location request includes a request for > the desired routing information. This document specifies an > extension to the HELD protocol to support this funciton. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_E8FA0C2B-3072-4C8A-93EB-212C1AC19303 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This version of the draft addresses the comments that Keith = posted to the list during WGLC.

Cheers
James


Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-ietf-ecrit-held-routing-03.txt
Date: = 21 July 2015 5:00:11 pm AEST
To: = "Laura Liess" <L.Liess@telekom.de>, = "James Winterbottom" <a.james.winterbottom@gmail.com>, "Hannes Tschofenig" = <hannes.tschofenig@gmx.net>, "Laura Liess" <l.liess@telekom.de>, = "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>, "James Winterbottom" = <a.james.winterbottom@gmail.com>


A = new version of I-D, draft-ietf-ecrit-held-routing-03.txt
has= been successfully submitted by James Winterbottom and posted to the
IETF repository.

Name: = draft-ietf-ecrit-held-routing
Revision: 03
Title:= = A Routing Request Extension for the HELD Protocol
Document date: 2015-07-20
Group:= = ecrit
Pages: 14
URL: =            https://www.ietf.org/internet-drafts/draft-ietf-ecrit-held-rout= ing-03.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-ecrit-held-routing/=
Htmlized:       https://tools.ietf.org/html/draft-ietf-ecrit-held-routing-03
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-held-routi= ng-03

Abstract:
=   For cases where location servers have access to emergency = routing
  information they are able to return = routing information with the
  location = information if the location request includes a request for
=   the desired routing information.  This document = specifies an
  extension to the HELD protocol = to support this funciton.




Please note that it may take a couple of = minutes from the time of submission
until the htmlized = version and diff are available at tools.ietf.org.

The IETF = Secretariat


= --Apple-Mail=_E8FA0C2B-3072-4C8A-93EB-212C1AC19303-- From nobody Wed Jul 22 09:29:28 2015 Return-Path: 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 2106B1ACE69 for ; Wed, 22 Jul 2015 09:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.38 X-Spam-Level: * X-Spam-Status: No, score=1.38 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 PbpDvnabi5Ji for ; Wed, 22 Jul 2015 09:29:25 -0700 (PDT) Received: from smtpdb7.aruba.it (smtpdb7.aruba.it [62.149.158.249]) by ietfa.amsl.com (Postfix) with ESMTP id DD4041A8A16 for ; Wed, 22 Jul 2015 09:27:39 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd03.ad.aruba.it with bizsmtp id vUTe1q01J2NEPrz01UTfoG; Wed, 22 Jul 2015 18:27:39 +0200 Date: Wed, 22 Jul 2015 18:27:40 +0200 (CEST) From: Meetecho Team To: ecrit@ietf.org Message-ID: <18434297.3.1437582460321.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2_637716982.1437582460319" Archived-At: Subject: [Ecrit] Meetecho recordings of ECRIT WG session X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 16:29:27 -0000 ------=_Part_2_637716982.1437582460319 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the ECRIT WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#ECRIT In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_2_637716982.1437582460319--