Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D526112D0D1 for ; Wed, 6 Jul 2016 07:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 UfiNQH1gtnIs for ; Wed, 6 Jul 2016 07:58:26 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C2912B01A for ; Wed, 6 Jul 2016 07:58:05 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Wed, 6 Jul 2016 10:58:04 -0400 From: Yuval Lifshitz To: "lionel.morand@orange.com" , "jouni.nospam@gmail.com" , Dave Dolson , "Gardella, Maryse (Nokia - FR)" , "dime@ietf.org" Thread-Topic: [Dime] RFC 4006 bis - IMEI Thread-Index: AQHR0vZJ6ucLEjBkbE6Ga3VB4LLp1aADzpSAgABFm4CABgfIgIAAJcUAgAAQ6QCAAAp3gIAA30IAgABneID//+MbAA== Date: Wed, 6 Jul 2016 14:58:03 +0000 Message-ID: References: <21004_1467738570_577BE9CA_21004_4347_1_6B7134B31289DC4FAF731D844122B36E01EE3EDA@OPEXCLILM43.corporate.adroot.infra.ftgroup> <19142_1467808734_577CFBDE_19142_892_1_6B7134B31289DC4FAF731D844122B36E01EE59A0@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <19142_1467808734_577CFBDE_19142_892_1_6B7134B31289DC4FAF731D844122B36E01EE59A0@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] RFC 4006 bis - IMEI X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 14:58:29 -0000 Having two codes is surely better.=20 My comment was regarding the current state, and the urgency of the change -= since the value is overloaded in one AVP/IE in RADIUS/GTP-C, it is probabl= y overloaded in the Diameter AVP when type is IMEISV. -----Original Message----- From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: Wednesday, July 06, 2016 3:39 PM To: Yuval Lifshitz; jouni.nospam@gmail.com; Dave Dolson; Gardella, Maryse (= Nokia - FR); dime@ietf.org Subject: RE: [Dime] RFC 4006 bis - IMEI There is a lot of historical stuff in 3GPP specifications, depending on the= release for which the specification was first edited. After a lot of discussion, the formats of IMEI/IMEISV have been clarified i= n the TS 23.003, defined as two distinct identifiers: IMEI =3D TAC | SNR |CD/SD 8-D 6-D 1-D IMEISV =3D TAC | SNR | SVN 8-D 6-D 2-D On some 3GPP interfaces, these Ids are conveyed into two different 3GPP-spe= cific AVPs. In such a case, they is no need to use the length to different = one from this other. And we are not running out of AVP codes. So no need to encapsulate in the s= ame AVP two values with two different semantics. regards, Lionel > -----Message d'origine----- > De=A0: Yuval Lifshitz [mailto:ylifshitz@sandvine.com] Envoy=E9=A0: mercre= di=20 > 6 juillet 2016 12:41 =C0=A0: MORAND Lionel IMT/OLN;=20 > jouni.nospam@gmail.com; Dave Dolson; Gardella, Maryse (Nokia - FR);=20 > dime@ietf.org Cc=A0: Yuval Lifshitz Objet=A0: RE: [Dime] RFC 4006 bis -=20 > IMEI >=20 > * In 3GPP TS 29.061 they use the AVP length to differentiate IMEI from=20 > IMEISV in the RADIUS AVP > * In 3GPP TS 29.060 (GTP-C) they pad with ones in case that the=20 > software version is not there >=20 > So, my guess is that the gateway is probably using one of the above=20 > options in when sending the value over Diameter. So, it is probably=20 > safe to assume that the IMEISV enum is used to send both types of data. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=20 > lionel.morand@orange.com > Sent: Tuesday, July 05, 2016 8:09 PM > To: jouni.nospam@gmail.com; Dave Dolson; Gardella, Maryse (Nokia -=20 > FR); dime@ietf.org > Subject: Re: [Dime] RFC 4006 bis - IMEI >=20 > For clarification, for Diameter related IANA allocation requests, it=20 > is under the responsibility of CT4 secretary. >=20 > Now, as said by Dave and Jouni, we should clarify the requirement for=20 > an IMEI specific value whereas only the IMEISV is actually used. >=20 > Regards, >=20 > Lionel >=20 > > -----Message d'origine----- > > De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni=20 > > Korhonen Envoy=E9=A0: mardi 5 juillet 2016 18:32 =C0=A0: Dave Dolson;=20 > > Gardella, Maryse (Nokia - FR); dime@ietf.org Objet=A0: Re: [Dime] RFC=20 > > 4006 bis - IMEI > > > > Designated experts would most likely be either Lionel or me.=20 > > Basically the procedure goes like: there's a public spec (no need to=20 > > be in IETF) or at least technical discussion (preferably in IETF) of=20 > > the allocation need of the new code point, and once that is "done"=20 > > someone does a request to IANA. Then IANA will contact the "expert",=20 > > who evaluates the allocation requests and either grants or denies=20 > > it. The more information there is available for the allocation=20 > > requests the more > comfortble the expert is backing up the request towards IANA. > > > > For example various 3GPP CT group secretaries have done allocation=20 > > requests to IANA during years. > > > > Regarding the User-Equipment-Info-Type AVP doing the new allocation=20 > > doing it in RFC4006bis would be "easy".. assuming we finish this=20 > > discussion into an agreement for a need. > > > > - Jouni > > > > 7/5/2016, 8:31 AM, Dave Dolson kirjoitti: > > > Maryse, > > > Referring to BCP26, https://tools.ietf.org/html/bcp26, > > > You can read about "Assignment by Designated Expert" in section 3 > > > https://tools.ietf.org/html/bcp26#section-3 > > > > > > I don't know who the designated expert would be, but I think the=20 > > > first step > > would be to begin a thread on the dime mailing list to request the=20 > > new allocation, justifying why it is needed. > > > > > > Hopefully the dime chairs can provide more insight on the process. > > > > > > -Dave > > > > > > > > > -----Original Message----- > > > From: Gardella, Maryse (Nokia - FR)=20 > > > [mailto:maryse.gardella@nokia.com] > > > Sent: Tuesday, July 05, 2016 9:16 AM > > > To: Dave Dolson; dime@ietf.org > > > Subject: RE: [Dime] RFC 4006 bis - IMEI > > > > > > Hi Dave, > > > > > > Do you mean, in case this new value would be needed, it is=20 > > > possible to handle > > this via IANA allocation w/o impacting existing RFC 4006? Could you=20 > > clarify this for me? > > > > > > Thanks > > > Maryse > > > > > > -----Original Message----- > > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson > > > Sent: vendredi 1 juillet 2016 19:11 > > > To: Gardella, Maryse (Nokia - FR); dime@ietf.org > > > Subject: Re: [Dime] RFC 4006 bis - IMEI > > > > > > Maryse, > > > OK, I understand your question. > > > > > > Reading 3GPP 23.003, IMEI and IMEISV are clearly defined as=20 > > > different things > > in sections 6.2.1 and 6.2.2. > > > And RFC4006 specifically says IMEISV. > > > > > > So I would say RFC4006 is not ambiguous. > > > > > > Also, the most recent 3GPP 32.299 indicates "The used value is 0=20 > > > for the > > international mobile equipment identifier and software version=20 > > according to 3GPP TS 23.003." > > > > > > It seems reasonable to extend to a Type 4 for IMEI, but there does=20 > > > not seem > > to have been a need, or there would have been an IANA allocation=20 > > (which does not require RFC revision). > > > > > > Perhaps you could explain the need to the group? > > > > > > -Dave > > > > > > > > > -----Original Message----- > > > From: Gardella, Maryse (Nokia - FR)=20 > > > [mailto:maryse.gardella@nokia.com] > > > Sent: Friday, July 01, 2016 9:02 AM > > > To: Dave Dolson; dime@ietf.org > > > Subject: RE: [Dime] RFC 4006 bis - IMEI > > > > > > Hi Dave, > > > > > > Indeed it was not clear to me whether the current definition=20 > > > explicitly excluded > > the IMEI or not. > > > I was wondering about the behavior of the client in case the=20 > > > Software Version > > Number (SVN) is not available. > > > > > > Otherwise if a new value is needed for this distinction, I would=20 > > > propose the User-Equipment-Info-Type AVP to be extended with IMEI=20 > > > value > > > > > > > > > BR > > > Maryse > > > > > > -----Original Message----- > > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson > > > Sent: jeudi 30 juin 2016 19:39 > > > To: Gardella, Maryse (Nokia - FR); dime@ietf.org > > > Subject: Re: [Dime] RFC 4006 bis - IMEI > > > > > > Maryse, > > > > > > If I understand correctly, you are proposing overloading a type,=20 > > > distinguishing > > the types only by length. > > > > > > Is there precedent for the overloading you propose, such as a 3GPP=20 > > > standard > > or de facto standard usage that you can cite? > > > > > > Otherwise, IANA may assign new values for new types, and we aren't=20 > > > short on > > space: > > > http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtm > > > l# > > > aa > > > a-parameters-41 > > > > > > > > > -Dave > > > > > > > > > > > > -----Original Message----- > > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Gardella,=20 > > > Maryse (Nokia - FR) > > > Sent: Thursday, June 30, 2016 12:59 PM > > > To: dime@ietf.org > > > Subject: [Dime] RFC 4006 bis - IMEI > > > > > > All, > > > > > > As part of the updates to RFC 4006 I propose to consider the IMEI=20 > > > also when > > refering to IMEISV, otherwise it is not clear if=20 > > User-Equipment-Info-Type value O can be used for IMEI. > > > > > > > > > In section 8.50. User-Equipment-Info-Type AVP in RFC4006,the=20 > > > following is > > specified: > > > > > > IMEISV 0 > > > The identifier contains the International Mobile Equipment > > > Identifier and Software Version in the international IMEISV for= mat > > > according to 3GPP TS 23.003 [3GPPIMEI]. > > > > > > Which I propose to be updated as follows: > > > > > > IMEI(SV) 0 > > > The identifier contains the International Mobile Equipment > > > Identifier and Software Version in the international IMEISV for= mat, > > > or the International Mobile Equipment Identifier in the=20 > > > international > > IMEI format > > > according to 3GPP TS 23.003 [3GPPIMEI]. > > > > > > > > > Differentiation between IMEI (15 digits) and IMEISV (16 digits) is=20 > > > based on AVP > > length, would this work? > > > > > > BR > > > Maryse > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 > _________________________________________________________________ > ________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, Orange decline toute responsabilite si ce message a ete alt= ere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not=20 > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and=20 > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have=20 > been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you.