RE: Gen-ART IETF LC review of draft-allen-dispatch-imei-urn-as-instanceid-10
Roni Thank you for the review My responses below prepended with [AA] Andrew From: Roni Even [mailto:ron.even@gmail.com] Sent: Monday, August 05, 2013 8:35 AM To: draft-allen-dispatch-imei-urn-as-instanceid@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: Gen-ART IETF LC review of draft-allen-dispatch-imei-urn-as-instanceid-10 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-allen-dispatch-imei-urn-as-instanceid-10 Reviewer: Roni Even Review Date:2013-8-5 IETF LC End Date: 2013-8-16 IESG Telechat date: Summary: This draft is almost ready for publication as an Informational RFC. Major issues: Minor issues: Why is it going to be an Informational RFC, considering that there is a lot of normative language in the document. [AA] I think there are many other informational RFCs that contain normative language (e.g. RFC 3325 is informative and full of MUST statements). There is no intention to make this an IETF standard so therefore it cannot be standards track. This is being specified for 3GPP usage to meet the requirements of RFC 5626 that require publication of an RFC for specifying URNs that are used as instance-IDs. Nits/editorial comments: According to RFC editor guidelines (http://www.rfc-editor.org/policy.html#policy.abstract) the abstract section should not contain citations unless they are completely defined within the Abstract. [AA] This specification defines how the Uniform Resource Name namespace reserved for the GSMA (GSM Association) identities and its sub- namespace for the IMEI (International Mobile station Equipment Identity) can be used as an instance-id as specified in RFC 5626 [1] and also as used by RFC 5627 [2]. Its purpose is to fulfil the requirements in RFC 5626 [1] that state If a URN scheme other than UUID is used, the UA MUST only use URNs for which an RFC (from the IETF stream) defines how the specific URN needs to be constructed and used in the +sip.instance Contact header field parameter for outbound behavior. [AA] I think I can remove the as specified in RFC 5626 [1] and also as used by RFC 5627 [2] from the first sentence however I think the second sentence contains the relevant statement from the RFC so this is OK. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
SM The past discussions on this took place a couple of years ago involving primarily Cullen Jennings, Dale Worley and myself. Andrew - Original Message - From: S Moonesamy [mailto:sm+i...@elandsys.com] Sent: Tuesday, August 27, 2013 10:20 AM Central Standard Time To: Mary Barnes mary.h.bar...@gmail.com Cc: John C Klensin j...@jck.com; tb...@textuality.com tb...@textuality.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt Hi Mary, At 07:28 27-08-2013, Mary Barnes wrote: As far as the IPR, as the shepherd and DISPATCH WG co-chair, I posted a note to the DISPATCH WG mailing list before progressing this document to see if anyone had any concerns about the IPR disclosures, which had been discussed in the past and were updated when I asked the authors the requisite questions about IPR while doing the PROTO write-up. No concerns were raised with regards to the updated IPR disclosures (i.e., no one responded to that email). And, you can google draft montemurro ietf ipr archives to find past discussions such as this one: draft montemurro ietf ipr archives Thanks for the feedback. Somebody commented that: It has nothing to do with IPR which was extensively discussed on the dispatch list. I read the DISPATCH mailing list archives. I did not see that extensive discussion. My comment was about that. I do not have any problem with the document shepherd comments. Regards, S. Moonesamy - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Martin Further to our conversation on this topic in Berlin I now respond formerly on the list. 3GPP has defined the mobile terminal as performing the UA role since the very beginning of IMS. Therefore the mapping between the terminal and the instance ID in IMS is a one to one relationship. Andrew - Original Message - From: Martin Thomson [mailto:martin.thom...@gmail.com] Sent: Monday, July 22, 2013 12:57 PM Central Standard Time To: Andrew Allen Cc: tb...@textuality.com tb...@textuality.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On 20 July 2013 15:34, Andrew Allen aal...@blackberry.com wrote: There are obviously always alternative design choices but why would you want to include both a pre assigned device ID and a generated device ID in the same message? I think that reading this thread should provide you with ample reasons. The instance ID in outbound has certain stability requirements that do not strictly correspond to the lifetime of the hardware in use. The other use cases answer very different questions, which include: is this a stolen device, is this device authorized to use the networks, etc... I'm certain those questions can be answered without a device identifier traversing the network. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Berlin was awesome, let's come again
Temperature Moderate - and wet and foggy. If you like to see the sun then you are unlikely to be happy in Vancouver in November. - Original Message - From: Deen, Glenn (NBCUniversal) [mailto:glenn.d...@nbcuni.com] Sent: Friday, August 02, 2013 07:05 AM Central Standard Time To: Eggert, Lars l...@netapp.com Cc: Carsten Bormann c...@tzi.org; ietf@ietf.org list ietf@ietf.org Subject: Re: Berlin was awesome, let's come again Vancouver will be great. I'm looking forward to it. The pacific helps keep it moderate during winter unless you go up in elevation such as the local mountains. Glenn Sent from my cell, please forgive the typos On Aug 2, 2013, at 1:58 PM, Eggert, Lars l...@netapp.com wrote: On Aug 2, 2013, at 13:56, Deen, Glenn (NBCUniversal) glenn.d...@nbcuni.com wrote: -1 on doing it during the winter speaking as a Californian who doesn't even own a winter coat You are not going to like going to Vancouver for IETF-88... Lars - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
The reason why the IMEI namespace is being registered as a GSMA namespace and not as part of the 3GPP namespace is that the GSMA has the responsibility for IMEI assignment and hence in maintaining uniqueness of the namespace. It has nothing to do with IPR which was extensively discussed on the dispatch list. The primary purpose of the IMEI is for preventing use of stolen mobile phones and enabling emergency calls to be made from mobiles that don't have a valid subscription. Andrew - Original Message - From: S Moonesamy [mailto:sm+i...@elandsys.com] Sent: Saturday, July 20, 2013 10:48 PM Central Standard Time To: John C Klensin j...@jck.com Cc: Tim Bray tb...@textuality.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt Hi John, At 18:23 20-07-2013, John C Klensin wrote: See my earlier note, but mostly to aid in getting the documentation right. For example, to the extent that the recent discussion results in a more complete treatment of privacy and/or security considerations in the documentation, that is a net improvement and added value. There was a Last Call for draft-montemurro-gsma-imei-urn-01 in 2007. The draft was sponsored by an Apps AD. draft-montemurro-gsma-imei-urn-04 was evaluated (I did not verify the details) in 2009. An IPR disclosure, about a patent filed several years ago, was filed after that evaluation. The DISCUSS got cleared automatically. draft-montemurro-gsma-imei-urn-08 was dispatched to RAI in 2011. 3GPP was assigned a URN in 2008. The shepherd write-up for draft-montemurro-gsma-imei-urn-16 mentions that this document is required for the 3GPP/IMS specification, thus any vendor that implements the 3GPP specifications follows this specification. The significant difference between the 3GPP URN and the requested GSMA URN is that there is an IPR disclosure on that latter. One of the questions asked by Tim Bray was about the WiFi-only scenario. That was raised previously through a DISCUSS as the softphone issue. The privacy discussion might cause some discontent. As for whether the draft will gain consensus, well, what can I say; if it is the consensus of the IETF to support state-sponsored surveillance there is nothing I can do about it. :-) Regards, S. Moonesamy - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid is also required in order to use the IMEI as a SIP instance ID. So just not registering the sub namespace doesn't avoid the IETF having to address the issue. As John pointed out having the sub namespace reviewed by IETF provides the opportunity to add text to address privacy concerns with any inappropriate usage. - Original Message - From: S Moonesamy [mailto:sm+i...@elandsys.com] Sent: Saturday, July 20, 2013 06:50 PM Central Standard Time To: Andrew Allen Cc: scott.b...@gmail.com scott.b...@gmail.com; sm+i...@elandsys.com sm+i...@elandsys.com; ietf@ietf.org ietf@ietf.org; tb...@textuality.com tb...@textuality.com; draft-montemurro-gsma-imei-urn@tools.ietf.org draft-montemurro-gsma-imei-urn@tools.ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt Hi Andrew, At 13:48 20-07-2013, Andrew Allen wrote: I think IANA registration of namespaces has a lot of value. draft-montemurro-gsma-imei-urn-16 discusses about two namespaces: (i) gsma (ii) imei It is not possible to get a IANA registration for (ii) as according to draft-montemurro-gsma-imei-urn-16 (ii) is managed by (i). In simple terms (ii) does not require IETF approval. Regards, S. Moonesamy - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Tim Seems the text got munged with some copy pasting so here it is corrected: Firstly as stated in http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ the use of the IMEI as a SIP Instance ID only pertains to usage of SIP with the 3GPP IMS and if a device is not using IMS without an IMEI then it will use a UUID as the SIP instance ID as per RFC 5626. If a device without an IMEI uses IMS then it will also still use a UUID as the SIP instance ID as per RFC 5626. This is specified also in the 3GPP IMS specification TS 24.229 as well as the above draft. So applications running on devices that don't have an IMEI can still use SIP for sessions. The IMEI which has been used in mobile devices for 20 years also survives device wipes for the circuit switched calling capability as used by billions of mobiles today with 2G and 3G networks. So again how is this more harmful for 4G than the current situation with 2G and 3G if a mobile device is transferred to a new owner? Andrew From: Andrew Allen [mailto:aal...@blackberry.com] Sent: Saturday, July 20, 2013 11:48 PM Central Standard Time To: tb...@textuality.com tb...@textuality.com Cc: ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt Tim Firstly as stated in http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ the use of the IMEI as a SIP Instance ID only pertains to usage of SIP with the 3GPP IMS and if a device is not using IMS sing IMS without an IMEI uses IMS then it will still use a UUID as the SIP instance ID as per RFC 5626. If a device without an IMEI uses IMS then it will also still use a UUID as the SIP instance ID as per RFC 5626. This is specified also in the 3GPP IMS specification TS 24.229 as well as the above draft. So applications running on devices that don't have an IMEI can still use SIP for sessions. The IMEI which has been used in mobile devices for 20 years also survives device wipes for the circuit switched calling capability as used by billions of mobiles today with 2G and 3G networks. So again how is this more harmful for 4G than the current situation with 2G and 3G if a mobile device is transferred to a new owner? Andrew From: Tim Bray [mailto:tb...@textuality.com] Sent: Saturday, July 20, 2013 07:01 PM Central Standard Time To: Andrew Allen Cc: scott.b...@gmail.com scott.b...@gmail.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Sat, Jul 20, 2013 at 3:20 PM, Andrew Allen aal...@blackberry.commailto:aal...@blackberry.com wrote: Can it please be explained how the IMEI URN when used as stated in http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ Is any more harmful than as the IMEI is used today by over 90% of mobile phones in use today worldwide? It survives device wipes, which usually happen upon change of device ownership. I’m not an expert in your application domain, so pardon me if this question is hopelessly naive: It seems that this identifier is related in some way to SIP sessions. It seems that it would be a common operation to launch a SIP session on a device such as a WiFi-only tablet, or an iPod touch, that doesn’t have an IMEI. Is this a problem? -T Andrew - Original Message - From: Scott Brim [mailto:scott.b...@gmail.commailto:scott.b...@gmail.com] Sent: Saturday, July 20, 2013 03:55 PM Central Standard Time To: Andrew Allen Cc: tb...@textuality.commailto:tb...@textuality.com tb...@textuality.commailto:tb...@textuality.com; ietf@ietf.orgmailto:ietf@ietf.org ietf@ietf.orgmailto:ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Sat, Jul 20, 2013 at 4:08 PM, Andrew Allen aal...@blackberry.commailto:aal...@blackberry.com wrote: Tim The quote is from RFC 5626 which also states: 3.1. Summary of Mechanism Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled. Since the UUID in the instance ID is also static how is this significantly different in terms of privacy concerns from the IMEI being used as an instance ID? You're not demonstrating that an IMEI is just as good, you're demonstrating that a UUID is just as bad. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
The URN containing the IMEI is used by all mobile phones that support voice over LTE. It is a dependency for 3GPP release 8 (which was completed about end of 2008). So yes it is going to be used and its more than 3 years of 3GPP work invested and is already incorporated into many devices. In the pre-existing circuit switched systems the IMEI is delivered to the network as the device identifier and it is also necessary to deliver the same device identifier to the network when using SIP so that when handover takes place between packet switched and circuit switched the network can correlate the communication as being with the same device. Regulations also require the IMEI to be delivered to the network. This associated draft describes how 3GPP uses the IMEI as a SIP instance ID and the reasons why: http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ - Original Message - From: Scott Brim [mailto:scott.b...@gmail.com] Sent: Saturday, July 20, 2013 06:23 AM Central Standard Time To: S Moonesamy sm+i...@elandsys.com Cc: Tim Bray tb...@textuality.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt Thanks, SM, for finding what I said back in 2010. I still think this is architected wrong, conflating devices with communication endpoints higher up the stack, and steers us toward a path toward eventually needing to reduce privacy even more. However, 3GPP has apparently already already started marching down that path. Could our liaison explain the situation there? Is anyone actually going to use it? Is this a done deal - do we have to support it because otherwise 3 years of 3GPP work get undone? Scott - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Tim The quote is from RFC 5626 which also states: 3.1. Summary of Mechanism Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled. Since the UUID in the instance ID is also static how is this significantly different in terms of privacy concerns from the IMEI being used as an instance ID? Andrew From: Tim Bray [mailto:tb...@textuality.com] Sent: Friday, July 19, 2013 10:58 AM Central Standard Time To: Andrew Allen Cc: ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Fri, Jul 19, 2013 at 8:38 AM, Andrew Allen aal...@blackberry.commailto:aal...@blackberry.com wrote: I suggest you also read http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ Quoting from that document: “If a URN scheme other than UUID is used, the UA MUST only use URNs for which an RFC (from the IETF stream) defines how the specific URN needs to be constructed...” Now, I’m not an expert in the 3GPP world; but the suggestion in that extract that UUIDs are a better choice than a (shaky, unreliable, privacy-problematic) device identifier certainly rings true for those of us who think at the apps level. -T That will explain the primary application of this URN which is intended for use in the 3GPP cellular standards. Andrew From: Tim Bray [mailto:tb...@textuality.commailto:tb...@textuality.com] Sent: Friday, July 19, 2013 10:02 AM Central Standard Time To: IETF-Discussion Discussion ietf@ietf.orgmailto:ietf@ietf.org Subject: Last call: draft-montemurro-gsma-imei-urn-16.txt Just wanted to point out that both Apple (for iOS) and Google (for Android) have strongly discouraged the use of IMEI to identify devices for the purposes of application software. There are privacy, quality, and availability issues with their use. Apple has removed the ability of developers to work with the (often IMEI-derived) “Universal Device ID” (see http://blogs.avg.com/mobile-2/apple-ios-7-puts-unique-device-ids/) and Google has officially deprecated their use: http://android-developers.blogspot.ca/2011/03/identifying-app-installations.html I’m not sure from reading the draft what the goal of having this URN namespace is, but if it involves encouraging its use by application developers, I’m pretty sure it’s a bad idea. -Tim - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Tim Mobile phones are not usually completely factory reset if resold and even if they were a UUID may still have been stored in non volatile as it may have been generated during final test. In any case if the IMEI was to persist after a resale how would that be a privacy problem given the restrictions placed on the usage in http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/? The intention is that the IMEI is not passed to the remote party except when required by regulations for an Emergency call. Andrew From: Tim Bray [mailto:tb...@textuality.com] Sent: Saturday, July 20, 2013 03:31 PM Central Standard Time To: Andrew Allen Cc: ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Sat, Jul 20, 2013 at 1:08 PM, Andrew Allen aal...@blackberry.commailto:aal...@blackberry.com wrote: The quote is from RFC 5626 which also states: 3.1. Summary of Mechanism Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled. Since the UUID in the instance ID is also static how is this significantly different in terms of privacy concerns from the IMEI being used as an instance ID? The difference is that the UUID (properly) vanishes when the device is factory-reset (“wiped”), as is common when a device is passed on to a new owner. The IMEI persists, however. -T Andrew From: Tim Bray [mailto:tb...@textuality.commailto:tb...@textuality.com] Sent: Friday, July 19, 2013 10:58 AM Central Standard Time To: Andrew Allen Cc: ietf@ietf.orgmailto:ietf@ietf.org ietf@ietf.orgmailto:ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Fri, Jul 19, 2013 at 8:38 AM, Andrew Allen aal...@blackberry.commailto:aal...@blackberry.com wrote: I suggest you also read http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ Quoting from that document: “If a URN scheme other than UUID is used, the UA MUST only use URNs for which an RFC (from the IETF stream) defines how the specific URN needs to be constructed...” Now, I’m not an expert in the 3GPP world; but the suggestion in that extract that UUIDs are a better choice than a (shaky, unreliable, privacy-problematic) device identifier certainly rings true for those of us who think at the apps level. -T That will explain the primary application of this URN which is intended for use in the 3GPP cellular standards. Andrew From: Tim Bray [mailto:tb...@textuality.commailto:tb...@textuality.com] Sent: Friday, July 19, 2013 10:02 AM Central Standard Time To: IETF-Discussion Discussion ietf@ietf.orgmailto:ietf@ietf.org Subject: Last call: draft-montemurro-gsma-imei-urn-16.txt Just wanted to point out that both Apple (for iOS) and Google (for Android) have strongly discouraged the use of IMEI to identify devices for the purposes of application software. There are privacy, quality, and availability issues with their use. Apple has removed the ability of developers to work with the (often IMEI-derived) “Universal Device ID” (see http://blogs.avg.com/mobile-2/apple-ios-7-puts-unique-device-ids/) and Google has officially deprecated their use: http://android-developers.blogspot.ca/2011/03/identifying-app-installations.html I’m not sure from reading the draft what the goal of having this URN namespace is, but if it involves encouraging its use by application developers, I’m pretty sure it’s a bad idea. -Tim - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - This transmission (including any attachments) may contain confidential information, privileged material (including material
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
I think IANA registration of namespaces has a lot of value. From: Tim Bray [mailto:tb...@textuality.com] Sent: Saturday, July 20, 2013 01:36 PM Central Standard Time To: Andrew Allen Cc: scott.b...@gmail.com scott.b...@gmail.com; sm+i...@elandsys.com sm+i...@elandsys.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt So if it’s going to be used, exactly as specified, whatever we do, then what value is added by the IETF process? -T On Sat, Jul 20, 2013 at 11:28 AM, Andrew Allen aal...@blackberry.commailto:aal...@blackberry.com wrote: The URN containing the IMEI is used by all mobile phones that support voice over LTE. It is a dependency for 3GPP release 8 (which was completed about end of 2008). So yes it is going to be used and its more than 3 years of 3GPP work invested and is already incorporated into many devices. In the pre-existing circuit switched systems the IMEI is delivered to the network as the device identifier and it is also necessary to deliver the same device identifier to the network when using SIP so that when handover takes place between packet switched and circuit switched the network can correlate the communication as being with the same device. Regulations also require the IMEI to be delivered to the network. This associated draft describes how 3GPP uses the IMEI as a SIP instance ID and the reasons why: http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ - Original Message - From: Scott Brim [mailto:scott.b...@gmail.commailto:scott.b...@gmail.com] Sent: Saturday, July 20, 2013 06:23 AM Central Standard Time To: S Moonesamy sm+i...@elandsys.commailto:sm%2bi...@elandsys.com Cc: Tim Bray tb...@textuality.commailto:tb...@textuality.com; ietf@ietf.orgmailto:ietf@ietf.org ietf@ietf.orgmailto:ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt Thanks, SM, for finding what I said back in 2010. I still think this is architected wrong, conflating devices with communication endpoints higher up the stack, and steers us toward a path toward eventually needing to reduce privacy even more. However, 3GPP has apparently already already started marching down that path. Could our liaison explain the situation there? Is anyone actually going to use it? Is this a done deal - do we have to support it because otherwise 3 years of 3GPP work get undone? Scott - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Equivalence is equivalence the rest seems subjective to me - is the glass half full or half empty. The point is they are no more or less harmful. Can it please be explained how the IMEI URN when used as stated in http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ Is any more harmful than as the IMEI is used today by over 90% of mobile phones in use today worldwide? Andrew - Original Message - From: Scott Brim [mailto:scott.b...@gmail.com] Sent: Saturday, July 20, 2013 03:55 PM Central Standard Time To: Andrew Allen Cc: tb...@textuality.com tb...@textuality.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Sat, Jul 20, 2013 at 4:08 PM, Andrew Allen aal...@blackberry.com wrote: Tim The quote is from RFC 5626 which also states: 3.1. Summary of Mechanism Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled. Since the UUID in the instance ID is also static how is this significantly different in terms of privacy concerns from the IMEI being used as an instance ID? You're not demonstrating that an IMEI is just as good, you're demonstrating that a UUID is just as bad. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Martin There are obviously always alternative design choices but why would you want to include both a pre assigned device ID and a generated device ID in the same message? Andrew - Original Message - From: Martin Thomson [mailto:martin.thom...@gmail.com] Sent: Friday, July 19, 2013 11:25 AM Central Standard Time To: Andrew Allen Cc: tb...@textuality.com tb...@textuality.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On 19 July 2013 08:38, Andrew Allen aal...@blackberry.com wrote: I suggest you also read http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ I read that document. The placement of IMEI in the instance id is a little bit of a non-sequitur to my thinking. There are three cases identified where it might be necessary to convey an IMEI, but no real motivation is provided for why it has to be included, specifically, in the instance ID. Nor is it the case that all of these cases necessarily require that IMEI is conveyed in the clear. I can imagine solutions to the real problems that do not require that an IMEI transit the network. However, I'll concede that the relationship between a network provider and the devices that use the network does not necessarily grant those devices any right protections of the form in which Tim seems to be assuming to be necessary. The real risk here is with scope of use. I'd have thought that a P- header would have been more appropriate for these use cases. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Tim This is not the normal 3GPP IMS scenario. In IMS the device as a whole is considered as a single UA, multiple IMS applications will need to share a common registration procedure that is provided by the underlying OS. Otherwise multiple IMS registrations from different applications on a 3GPP terminal will likely conflict with each other if they do not share a common registration mechanism that registers all IMS apps using a common registration procedure. In IMS, contacts from the same entity are overwritten by subsequent registrations. Which means that if each app were to register individually then any contact parameters such as feature tags from a previous registered app would be overwritten by the latest registering app. Therefore the registration function and the instance ID will likely be part of the OS and not the application. In any case RFC 5626 says nothing about requiring instance IDs to be wiped or regenerated when the UA is transferred to another user or that the UA cannot be embedded in non volative. It doesn't even barr the instance ID being delivered to other users. http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ goes a lot further than RFC 5626 in addressing privacy of the instance ID in that regard. Andrew From: Tim Bray [mailto:tb...@textuality.com] Sent: Saturday, July 20, 2013 04:07 PM Central Standard Time To: Scott Brim scott.b...@gmail.com Cc: Andrew Allen; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt Except that for normal usages at the application level, the UUID is generated by the app and placed in its private per-app storage, which is always erased on a factory-reset. To Andrew Allen: I strongly recommend factory-resetting your phone before you sell it, and also factory-resetting any phones you buy second-hand, just to be sure. Most people do this, for good reason. -T On Sat, Jul 20, 2013 at 1:55 PM, Scott Brim scott.b...@gmail.commailto:scott.b...@gmail.com wrote: On Sat, Jul 20, 2013 at 4:08 PM, Andrew Allen aal...@blackberry.commailto:aal...@blackberry.com wrote: Tim The quote is from RFC 5626 which also states: 3.1. Summary of Mechanism Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled. Since the UUID in the instance ID is also static how is this significantly different in terms of privacy concerns from the IMEI being used as an instance ID? You're not demonstrating that an IMEI is just as good, you're demonstrating that a UUID is just as bad. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Randy Are you suggesting its not a problem if everyone were to just go off and define namespaces and not have them registered with IANA? I don't think that's a good precedence. The GSMA is the authoritative organisation for some identifers that have been used in billions of mobile devices for 20 years. Why should IETF deny them a namespace and a listing in the IANA registry for such identifers? If there are concerns with the usage of these identifiers those concerns should be addressed in the drafts that define the usage. Andrew - Original Message - From: Randy Bush [mailto:ra...@psg.com] Sent: Saturday, July 20, 2013 05:48 PM Central Standard Time To: Andrew Allen Cc: IETF Disgust ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt I think IANA registration of namespaces has a lot of value. let me ask the other side of the coin, in this case, what harm will be done by not making this an rfc and registering the imei uri? and i am not a fan of the mrs goldberg argument. randy - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Tim Firstly as stated in http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ the use of the IMEI as a SIP Instance ID only pertains to usage of SIP with the 3GPP IMS and if a device is not using IMS sing IMS without an IMEI uses IMS then it will still use a UUID as the SIP instance ID as per RFC 5626. If a device without an IMEI uses IMS then it will also still use a UUID as the SIP instance ID as per RFC 5626. This is specified also in the 3GPP IMS specification TS 24.229 as well as the above draft. So applications running on devices that don't have an IMEI can still use SIP for sessions. The IMEI which has been used in mobile devices for 20 years also survives device wipes for the circuit switched calling capability as used by billions of mobiles today with 2G and 3G networks. So again how is this more harmful for 4G than the current situation with 2G and 3G if a mobile device is transferred to a new owner? Andrew From: Tim Bray [mailto:tb...@textuality.com] Sent: Saturday, July 20, 2013 07:01 PM Central Standard Time To: Andrew Allen Cc: scott.b...@gmail.com scott.b...@gmail.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Sat, Jul 20, 2013 at 3:20 PM, Andrew Allen aal...@blackberry.commailto:aal...@blackberry.com wrote: Can it please be explained how the IMEI URN when used as stated in http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ Is any more harmful than as the IMEI is used today by over 90% of mobile phones in use today worldwide? It survives device wipes, which usually happen upon change of device ownership. I’m not an expert in your application domain, so pardon me if this question is hopelessly naive: It seems that this identifier is related in some way to SIP sessions. It seems that it would be a common operation to launch a SIP session on a device such as a WiFi-only tablet, or an iPod touch, that doesn’t have an IMEI. Is this a problem? -T Andrew - Original Message - From: Scott Brim [mailto:scott.b...@gmail.commailto:scott.b...@gmail.com] Sent: Saturday, July 20, 2013 03:55 PM Central Standard Time To: Andrew Allen Cc: tb...@textuality.commailto:tb...@textuality.com tb...@textuality.commailto:tb...@textuality.com; ietf@ietf.orgmailto:ietf@ietf.org ietf@ietf.orgmailto:ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Sat, Jul 20, 2013 at 4:08 PM, Andrew Allen aal...@blackberry.commailto:aal...@blackberry.com wrote: Tim The quote is from RFC 5626 which also states: 3.1. Summary of Mechanism Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled. Since the UUID in the instance ID is also static how is this significantly different in terms of privacy concerns from the IMEI being used as an instance ID? You're not demonstrating that an IMEI is just as good, you're demonstrating that a UUID is just as bad. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Certainly text can be added to the draft to address concerns. Could Tim please elaborate on what issues he sees when a device is transferred between owners and what potential uses of the URN he has a concern with? Certainly I can see that if it was used as address that had some permanence then that would be an issue however this is not the case as per http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ Andrew - Original Message - From: John C Klensin [mailto:john-i...@jck.com] Sent: Saturday, July 20, 2013 09:44 PM Central Standard Time To: Tim Bray tb...@textuality.com Cc: IETF-Discussion Discussion ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt --On Saturday, July 20, 2013 19:17 -0700 Tim Bray tb...@textuality.com wrote: Fair enough. I think it would be reasonable to ask that: - the draft include the word privacy - the draft discuss the issues around relying on an identifier that persists across changes in device ownership There may be an issue concerning a SIP-related identifier which is unavailable on millions of mobile devices which do not have IMEIs, but it's quite possible that it's non-applicable in the context of the draft. -T Personally, I'd consider getting all three of those issues addressed in the document (including a discussion of the applicability of the latter and a serious discussion of the privacy issues) as adding value... and as requirements for RFC publication in the IETF Stream. john - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Tim I suggest you also read http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ That will explain the primary application of this URN which is intended for use in the 3GPP cellular standards. Andrew From: Tim Bray [mailto:tb...@textuality.com] Sent: Friday, July 19, 2013 10:02 AM Central Standard Time To: IETF-Discussion Discussion ietf@ietf.org Subject: Last call: draft-montemurro-gsma-imei-urn-16.txt Just wanted to point out that both Apple (for iOS) and Google (for Android) have strongly discouraged the use of IMEI to identify devices for the purposes of application software. There are privacy, quality, and availability issues with their use. Apple has removed the ability of developers to work with the (often IMEI-derived) “Universal Device ID” (see http://blogs.avg.com/mobile-2/apple-ios-7-puts-unique-device-ids/) and Google has officially deprecated their use: http://android-developers.blogspot.ca/2011/03/identifying-app-installations.html I’m not sure from reading the draft what the goal of having this URN namespace is, but if it involves encouraging its use by application developers, I’m pretty sure it’s a bad idea. -Tim - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Tim Do you not think that the text in the security considerations section:: because IMEIs can be loosely correlated to a user, they need to be treated as any other personally identifiable information. In particular, the IMEI URN MUST NOT be included in messages intended to convey any level of anonymity covers the privacy issue? If not what is the additional privacy concern? Andrew From: Tim Bray [mailto:tb...@textuality.com] Sent: Friday, July 19, 2013 12:07 PM Central Standard Time To: S Moonesamy sm+i...@elandsys.com Cc: IETF-Discussion Discussion ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Fri, Jul 19, 2013 at 9:52 AM, S Moonesamy sm+i...@elandsys.commailto:sm+i...@elandsys.com wrote: It would be easier to have the draft discuss the GSMA URN only. The alternative is to have the draft discuss the privacy considerations of using IMEI and IMEISV. Good catch. Assuming this is a good idea (I’m dubious) it would be completely unacceptable to register it without a discussion of privacy implications. -T Regards, S. Moonesamy - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: IETF registration fee?
I think that misses the point. The WG sessions are where the issues are raised and the opinions and positions are stated. Offline over the food and drink in small groups is where the detailed discussion and finding of solutions to resolve those issues usually takes place. Such a phenomena is not unique to just IETF - its the nature of the beast. Andrew - Original Message - From: Keith Moore [mailto:mo...@network-heretics.com] Sent: Thursday, July 11, 2013 04:19 PM Central Standard Time To: ietf@ietf.org ietf@ietf.org Subject: Re: IETF registration fee? On 07/11/2013 04:50 PM, Brian E Carpenter wrote: Douglas, ... Those traveling thousands of miles already confront many uncertainties. Those that elect to participate remotely should be afforded greater certainty of being able to participate when problems occur at local venues or with transportation. Increasing participation without the expense of the brick and mortar and travel should offer long term benefits and increased fairness. How much would you be willing to pay for remote participation (assuming it was of high quality)? Not much. Remote participation misses the whole point of IETF meetings. Sure, it's useful to be able to listen on WG sessions and make a comment or two. But the WG sessions generally aren't actually worth very much, especially the way that they tend to be run these days. The most important work gets done in the hallways and over food and drink. So IETF is in this very strange position of supporting itself by charging a large amount of money for an activity that's mostly peripheral to getting useful work done. Keith - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Requirement to go to meetings
Randy I think that also assumes that the earth's rotation will also stop at some time during the next decade forcing us all to migrate to the sunny side of the planet. Failing that happening then with 18 hours at least (Tokyo to US West coast) of time zones (and that doesnt take into account places like Hawaii and NZ) haveing any regular or long time real time sessions is in my view impractical as someone has to do it in the middle of the night then. Andrew - Original Message - From: Randy Bush [mailto:ra...@psg.com] Sent: Sunday, October 23, 2011 12:47 PM To: Cullen Jennings flu...@cisco.com Cc: IETF Disgust ietf@ietf.org Subject: Re: Requirement to go to meetings perhaps we could model using the assumption that, a decade or so hence, there will be no physical meetings, [almost] all will be net-based. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 support in hotel contract?
+1 We can put all kinds of wonderful constraints on hotels if we want to - make sure they are enviromental friendly, non discriminatory in their hiring practices, donate to save whales and all kinds of other worthy causes and do things such as transitioning to IPv6 plus be really cheap and be in interesting and cheap to get to locations - then we will likely never be able to meet anywhere. IF IPv6 really requires IETF to use its business to influence hotels to adopt it then its a technolgy that deserves to go the way of the DoDo. IPv6 will be adopted because it is needed and brings commerical benefits to those that deploy it. - Original Message - From: Cullen Jennings [mailto:flu...@cisco.com] Sent: Thursday, October 20, 2011 11:57 PM To: George, Wes wesley.geo...@twcable.com Cc: i...@ietf.org i...@ietf.org; ietf@ietf.org ietf@ietf.org Subject: Re: IPv6 support in hotel contract? We just failed to manager to find a venue in Asia because there was no venue that meant all the constraints. I'd rather not add more constraints to the hotel selection. I love the taste of dog food, but v6 in the hotel is not something that I find critical to accomplish the task I come to IETF to get done. On Oct 20, 2011, at 7:01 AM, George, Wes wrote: My last message caused something else to occur to me – there has been a lot of discussion both here and at NANOG about hotels being woefully underprepared for the internet (and address) use that their guests generate when a conference full of geeks and their multiple devices per person descend upon them. Sometimes the IETF is successful at convincing the hotel to let them take over the internet service in the guest rooms, sometimes not. Perhaps we can kill two birds with one stone by starting to require IPv6 service in the guest rooms when we enter into negotiations with hotels. If they don’t have it, we’ll be happy to temporarily take over the internet service, or assist them in getting it enabled permanently in their existing network, and if neither of those options are acceptable, it provides negotiating leverage on other things. This also has the net effect of starting to make it clear to hotel management that IPv6 is going to start being mandatory for some subset of their guests before too much longer. I realize that having something in the contract doesn’t mean that we’re any more likely to get it. But the fact that it’s in the contract makes a statement in and of itself. IAOC, any reason why this couldn’t be added, especially given how far in advance you’re negotiating with venues? Thanks, Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 support in hotel contract?
George I think its fine to sell them on the advantages of transitioning but some others were advocating to have it in the contract. Any additional costs you place on the hotel will inevitably be reclaimed (with interest) in the room charges, cost of breaks, etc - there is no such thing as a free lunch! - Original Message - From: George, Wes [mailto:wesley.geo...@twcable.com] Sent: Friday, October 21, 2011 08:06 AM To: Andrew Allen; flu...@cisco.com flu...@cisco.com Cc: i...@ietf.org i...@ietf.org; ietf@ietf.org ietf@ietf.org Subject: RE: IPv6 support in hotel contract? From: Andrew Allen [mailto:aal...@rim.com] We can put all kinds of wonderful constraints on hotels if we want to - [snip] - then we will likely never be able to meet anywhere. [WEG] I am not suggesting that this be a deal-breaker constraint. We have quite a number of nice to have items that we will ask for, but not necessarily take our business elsewhere if we do not get. The sense I get from IAOC is that dates, capacity, and cost are the constraints. IPv6 support is window dressing (or deck chairs, depending on your perspective). IF IPv6 really requires IETF to use its business to influence hotels to adopt it then its a technolgy that deserves to go the way of the DoDo. IPv6 will be adopted because it is needed and brings commerical benefits to those that deploy it. [WEG] This is not an attempt to force *whether* IPv6 will be deployed, but when. Hotels are sort of an extension of the consumer space - right now, they don't know/care what IPv6 is, nor see a reason why it's necessary. It is quite unlikely that your average person will walk to the counter and say, your internet service is partially broken because it doesn't support IPv6. It is even less likely that this will happen enough times that they say, gosh, perhaps we need to look into this eye pee vee six thing... IETF has some leverage, and by definition should be on the early adopter curve, so I'm simply suggesting that they use it to accelerate the timeline a bit. From: Cullen Jennings [mailto:flu...@cisco.com] I love the taste of dog food, but v6 in the hotel is not something that I find critical to accomplish the task I come to IETF to get done. [WEG] We're working contracts for hotel venues 3+ years out at this point. How long are you willing to assume that IPv6 will not be critical to tasks that you need to do at IETF and that the IPv4 service in the hotel will be an acceptable alternative? Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
There likely are no such dates as there are telecommunications standards meetings of one kind or another virtually every week of the year (except Christmas and (western) new year). Many other standards organisations depend on IETF standards so it is important to avoid clashes with those organisations so those stakeholders can participate. It is desirable if the meetings are not back to back but that isn't always possible but direct clashes should be avoided especiallly since IETF only meets 3 times a year. Andrew - Original Message - From: Iljitsch van Beijnum [mailto:iljit...@muada.com] Sent: Monday, August 29, 2011 10:19 AM To: h...@uijterwaal.nl h...@uijterwaal.nl Cc: ietf@ietf.org ietf@ietf.org Subject: Re: voting system for future venues? On 29 Aug 2011, at 17:01 , Henk Uijterwaal wrote: If we want more flexibility in order to find better hotel deals, then we have to do something like: dates are fixed approximately 1.5 years out, and we do not mind having meetings back-to-back with other organizations on the clash list. That means that some folks will have to travel around the globe between Friday afternoon and Sunday morning in order to make it from one meeting to another. Is this so bad that $300/night room prices for hundreds of participants to avoid this issue is a good deal? One potential solution could be to select two or three weeks that don't clash or only minimally clash and then start the negotiations with a few more options, fixing the date a year or so out. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: A modest proposal for Friday meeting schedule
+1 with Adam - Original Message - From: Adam Roach [mailto:a...@nostrum.com] Sent: Monday, August 01, 2011 04:38 PM To: Russ Housley hous...@vigilsec.com Cc: IETF ietf@ietf.org Subject: Re: A modest proposal for Friday meeting schedule I'd like to join the sparse voices in speaking out against this plan. By Friday, I'm pretty well on a local meal schedule. Pushing lunch back by 2 hours would pretty well on guarantee that I'd be sugar-crashed and less coherent than normal by the end of Session II. /a On 8/1/11 10:10 AM, Russ Housley wrote: I am discussing the possibility with the Secretariat and the IESG. I will report back to the community as soon as possible. Russ On Jul 31, 2011, at 11:40 AM, Hadriel Kaplan wrote: Something like this: 8:30-11:00 Session I 11:15-12:15 Session II 12:30-13:30 Session III I really like it, as there are a bunch of post-IETF stuff, some of which starts in the afternoon and thus conflicts with the IETF. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [79all] IETF Badge
I agree here with Hadriel. If you don't have a badge because you didn't register and pay the fee then you don't belong here. If you lost or forgot your badge then I'm sure the secretariat would fix it and issue you a new one if you were registered. I didn't notice any oppressive security here- just smiling helpful people who insist on opening the meeting room doors for you. I seem to vaguely remember a long past IETF (maybe Washington DC) where in at least one WG we were asked to to wave our badges before the start of the session to show we were all legitimate attendees. So I don't think checking badges is totally new. Whether this was initiated by the hosts is in my view not relevant. The IETF rules state you need to pay the fees and register. If the host asks that those rules are enforced then so what. A prerequisite of any meeting is that you comply with the local regulations. If those regulations are not counter to IETF rules then there should be no issue. If they were then that's a different matter. Having some security checks on strangers protects to some extent the petty thefts of laptops that have become a frequent problem at meetings in large hotels. If the hosts were the primary driver for the checks (which seemed innoculous to me - but then I had me badge - but I doubt most of the (mainly) ladies on the doors were capable of putting most of us in an strong arm lock and marching us to exit door either) then they may have had very good and legit reasons such as compliance with insurance liability, fire regulations etc. Its also maybe more likely they were protecting against a bunch of free loaders feeding off the incredibly provisoned food at the breaks. I really don't see what all the fuss is about. Andrew - Original Message - From: Hadriel Kaplan [mailto:hkap...@acmepacket.com] Sent: Thursday, November 11, 2010 12:56 PM To: Peter Saint-Andre stpe...@stpeter.im Cc: Dave CROCKER d...@dcrocker.net; Henk Uijterwaal h...@ripe.net; dcroc...@bbiw.net dcroc...@bbiw.net; ietf@ietf.org ietf@ietf.org Subject: Re: [79all] IETF Badge On Nov 11, 2010, at 11:04 AM, Peter Saint-Andre wrote: Security on the terminal room is long-standing. It has equipment in it. To be fair, so might the meeting rooms (audio equipment, projectors, etc.). Perhaps in this instance the hotel was concerned about theft of such equipment. Equipment?? Considering the prices in the lobby bar, they were clearly protecting the coffee and tea! -hadriel p.s. I for one am glad they had strict badge checking - we're in the middle of a major city, and I don't want to worry about leaving my bag/laptop by my seat in a meeting room when I go up to the mic. (which in my case is too often) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [79all] IETF Badge
Well speech at IETF isn't free - it comes at the cost of 650 USD (advance registration) or a bit more on the door. If random locals want to come and make some kind of statement at IETF then all they have to do is come and do an on the door registration (at a fee of course) and make their statement at the microphone. Alternatively they could do it for free from the jabber room! I hardly think the badge check is an effective stop to that. - Original Message - From: Peter Saint-Andre [mailto:stpe...@stpeter.im] Sent: Thursday, November 11, 2010 07:57 PM To: Eliot Lear l...@cisco.com Cc: i...@ietf.org i...@ietf.org; Ole Jacobsen o...@cisco.com; Samuel Weiler weiler+i...@watson.org; ietf@ietf.org ietf@ietf.org Subject: Re: [79all] IETF Badge On 11/12/10 12:37 AM, Eliot Lear wrote: Is there is an unspoken concern in this discussion as to whether the host wanted to take names based on what people were saying, in the case they said something objectionable? There might be many unspoken objections, e.g. that a certain kind of host might want to keep random locals out of what could be perceived as a free speech zone. Peter -- Peter Saint-Andre https://stpeter.im/ - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Tourist or business visa from US?
Mary It seems you now also need a support letter from your own company too. When I tried to get my business visa for China last year they refused to process my application without such a support letter. This was the first time I had been asked for such a letter. Andrew From: Mary Barnes [mailto:mary.ietf.bar...@gmail.com] Sent: Tuesday, August 24, 2010 06:56 PM To: Ole Jacobsen o...@cisco.com Cc: ietf@ietf.org ietf@ietf.org Subject: Re: Tourist or business visa from US? My understanding is that the only difference in paperwork is the letter of invitation. Is there any other additional paperwork that is necessary? I would have thought that letters of invitation would be something the host had anticipated would be needed by the attendees - at least a subset. The wording on the meeting FAQ is somewhat nebulous as it notes that the secretariat won't provide the letters and that one is needed from the host, but there's no information on the process to request one. Do we just send an email to the individual listed as the contact for our visit? Mary. On Tue, Aug 24, 2010 at 5:49 PM, Ole Jacobsen o...@cisco.com wrote: There is no visa waiver program for China, at least not for any of the countries relevant to this discussion. You need a visa. Getting a tourist one is easier in the sense that it requires less paperwork and documentation. For a visit of duration ~ one week or so, there should be no issues with getting a tourist visa. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Tue, 24 Aug 2010, Mary Barnes wrote: U.S. customs is the least of my worries in this situation. In the 15 years that I've been attending these sorts of meetings, I've never needed a visa of any sort ahead of time. Can you please point me to an official website that suggests that there is a visa waiver program for us attending the IETF meeting in China? Mary. On Tue, Aug 24, 2010 at 3:44 PM, Behcet Sarikaya behcetsarik...@yahoo.comwrote: I agree with Fred. Many countries we go to attend IETF meetings would probably require business visa but we go there as tourists on a visa waiver program. On the way back as far as US customs are concerned the purpose is business but US customs never asks why you did not get a business visa. Regards, Behcet - Original Message From: todd glassey tglas...@earthlink.net To: ietf@ietf.org Sent: Tue, August 24, 2010 12:38:00 PM Subject: Re: Tourist or business visa from US? On 8/24/2010 8:24 AM, Fred Baker wrote: In the many times I have visited China, I have gotten a business visa once, and it was seriously not worth the effort. I plan to get a tourist visa. Except that now the PRC is looking at the purpose of your trip and that is to develop intellectual properties so this is not a personal but specifically a business trip. Does Cisco's legal department condone that Fred? Todd Glassey On Aug 24, 2010, at 7:43 AM, Andrew G. Malis wrote: Is there a consensus that a tourist visa is sufficient to attend the IETF from the US? Thanks, Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3091 - Release Date: 08/23/10 23:34:00 -- //- This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information
Re: China Visas
As someone who has entered China at least 13 times I can say that for at least US citizens and US residents the visa period usually starts the day of your intended entry into China not the day you apply. Obviously applicants need to BE AWARE and make sure the visa is valid for the meeting but for many of us it is essential that the invitation letters be available a long while in advance so we can apply without impacting other trips due to our passports being in cog nito Andrew - Original Message - From: Alexa Morris [mailto:amor...@amsl.com] Sent: Wednesday, July 28, 2010 01:15 PM To: jordi.pa...@consulintel.es jordi.pa...@consulintel.es Cc: ietf@ietf.org ietf@ietf.org Subject: Re: China Visas Information on the mechanics of the process has been online since IETF 77, Anaheim. However, we have not actually opened up the registration system, or started to issue letters of invitation yet, because of concerns that if a visa is granted too soon it would actually expire before the meeting time. Visas are good for 1-3 months only. We plan to open meeting registration the week of August 9. Letters of invitation will be available then as well. We have been told that this should provide plenty of time for people to obtain their visa. Alexa On Jul 28, 2010, at 10:12 AM, JORDI PALET MARTINEZ wrote: Well ... I tried to find it there several weeks ago, and again today, before making the question thru the list, and guess what, I'm still unable to find the right link to obtain my invitation letter. Regards, Jordi From: Jaap Akkerhuis j...@nlnetlabs.nl Reply-To: j...@nlnetlabs.nl Date: Wed, 28 Jul 2010 18:55:58 +0200 To: Jordi Palet Martínez jordi.pa...@consulintel.es Cc: ietf@ietf.org Subject: Re: China Visas For some of us traveling a lot, the only available time to get the VISA for next meeting will be vacations period in the next couple of weeks. However, I still don't see this being available in the meeting page. Can we please make sure to provide this in the next couple of days ? Google? :-) It is up here for weeks: http://www.ietf.org/meeting/upcoming.html and also at http://www.ietf.org/meeting/79/visa.html jaap ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: China Visas
Yes. Now a support letter from your compnay seems to be essential. Don't leave home without it :) From: Clint Chaplin [mailto:clint.chap...@gmail.com] Sent: Wednesday, July 28, 2010 10:02 PM To: Ole Jacobsen o...@cisco.com Cc: ietf@ietf.org ietf@ietf.org; JORDI PALET MARTINEZ jordi.pa...@consulintel.es Subject: Re: China Visas Ole, My intent in my previous email was not to point out possible differences between US and non-US citizens. The point was (and is) that the rules for US citizens seems to have recently changed, and as far as the SF consulate was concerned, they did not want an invitation letter for a business visa. Only a letter from my employer. On Wed, Jul 28, 2010 at 6:24 PM, Ole Jacobsen o...@cisco.com wrote: Clint, I am not suggesting that the requirements have changed, what I am suggesting is that the rules are not the same for US vs non-US citizens (the price certainly isn't ;-) and that this may lead you to get a visa which expires before you get to China. This happened to me once and the consulate very graciously and carefully removed the visa sticker and refunded the application fee. My confusing was the When do you intend to arrive in China? question. This date is NOT used in any way to determine the start date of the visa, so beware. Getting a tourist visa is perfectly fine according to our host and this does not require you to get an invitation letter, you're just required to submit proof that you did leave the hotel and visit tourist spots, start here: http://www.yikes.com/~ole/Beijing2009/IMG_3858-l.html :-) OK, I am kidding, but do please take some time to see Beijing!! The Chinese food is WAY better than what you're used to from home. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Wed, 28 Jul 2010, Clint Chaplin wrote: I applied to the SF consulate through a passport agency for a visa for a trip in March. At that time the passport agency let me know that the consulate did not need or want an invitation letter. All they required was a letter from my employer stating that they will guarantee my return, and asking for the visa level that I required. My letter from my employer asked for a one year multiple entry visa. I got it. I'm a US citizen. The requirements seem to have changed. On Wed, Jul 28, 2010 at 1:53 PM, Ole Jacobsen o...@cisco.com wrote: Jordi, I recommend you apply for a visa whenever it is convenient for you and when it will work according to the rules that apply (typically) for visas for Spain and that you go the tourist visa route since that type is easy. As discussed many months ago on this list, it is extremely difficult to give instructions beyond check with your local consulate or embassy for the exact rules and typical durations of the visa. In my case, for example, the duration typically granted by San Francisco (where I can walk into the consulate, past a certain group of prot..., oh, never mind) is DIFFERENT from Los Angeles, at least so I have been told by the visa wizards. Americans can typically get 6 months duration visas, but they pay $130 whereas I only pay $30. Nice arrangement, eh? :-) Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Wed, 28 Jul 2010, JORDI PALET MARTINEZ wrote: Hi Ole, In my case, I've been able to get a Chinese VISA in 3 previous occasions, more than 4 months in advance, which is also my typical average to by flights, book hotels, and so on to obtain lower fares. So should work also this time. From now to the next IETF meeting in China, I've only 1 slot of 7-on-a-row days at home, and during this week I also need to renew my passport (because the typical rule of expiry 6 months after the end of your trip), which in Spain, fortunately takes only a couple of hours. I know, I should have
Regarding RIM's recent IPR disclosures
With regard to the recent discussion on the IETF-Discussion list regarding RIM's recent IPR disclosures, I understand the community's concerns regarding the timeliness of the disclosure. As I'm sure everyone can understand, as employees of companies we are bound by confidentiality obligations and, in addition, cannot always control our company's internal processes. The community's concerns have been brought to the attention of my employer and they are in the process of evaluating the concerns. My company has asked for your patience while they take the time to evaluate the concerns and determine if there is an appropriate course of action in this matter to alleviate the concerns of the community. Your understanding is appreciated Best regards Andrew Allen Manager Standards Research In Motion Ltd Office +1 847-793-0861 x20824 BlackBerry Mobile +1 847 809 8636 http://www.rim.com/ http://www.rim.com/ - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
[Sip] Last Call: draft-ietf-sip-session-policy-framework (A Framework for Session Initiation Protocol (SIP) Session Policies) to Proposed Standard
Apologies for the late additional comment on this document. Based on some earlier comments I made on the SIP list we made the policyContactURI extensible to allow in the future the possibility to use other URI schemes for the policy channel other than SIP and SIPS. I think though that in order to ensure we don't have any future backward compatibility issues with other URI schemes we need to also include in the document a statement that UAs that receive policyContactURIs with URI schemes they don't understand in Policy-Contact headers must ignore those policyContactURIs. Andrew Allen Manager Standards Research In Motion Ltd Office +1 847-793-0861 x20824 BlackBerry Mobile +1 847 809 8636 http://www.rim.com/ http://www.rim.com/ - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
