Subject: Re: [Dime] RFC 4006 bis - IMEI

From: "Gardella, Maryse (Nokia - FR)" <[email-masked]>
Date: Fri, 1 Jul 2016 13:01:47 +0000

Hi Dave,

Indeed it was not clear to me whether the current definition explicitly excluded the IMEI or not.
I was wondering about the behavior of the client in case the Software Version Number (SVN) is not available. 

Otherwise if a new value is needed for this distinction, I would propose the User-Equipment-Info-Type AVP to be extended with IMEI value 

BR
Maryse

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: jeudi 30 juin 2016 19:39
To: Gardella, Maryse (Nokia - FR); [email-masked]
Subject: Re: [Dime] RFC 4006 bis - IMEI

Maryse,

If I understand correctly, you are proposing overloading a type, distinguishing the types only by length.

Is there precedent for the overloading you propose, such as a 3GPP standard or de facto standard usage that you can cite?

Otherwise, IANA may assign new values for new types, and we aren't short on space:
http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml#aaa-parameters-41

-Dave

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Gardella, Maryse (Nokia - FR)
Sent: Thursday, June 30, 2016 12:59 PM
To: [email-masked]
Subject: [Dime] RFC 4006 bis - IMEI

All,

As part of the updates to RFC 4006 I propose to consider the IMEI also when refering to IMEISV, otherwise it is not clear if User-Equipment-Info-Type value O can be used for IMEI. 

In section 8.50. User-Equipment-Info-Type AVP in RFC4006,the following is specified: 
  
 IMEISV                          0
      The identifier contains the International Mobile Equipment
      Identifier and Software Version in the international IMEISV format
      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 format, 
	or the International Mobile Equipment Identifier in the international IMEI format 
      according to 3GPP TS 23.003 [3GPPIMEI]. 

Differentiation between IMEI (15 digits) and IMEISV (16 digits) is based on AVP length, would this work?

BR
Maryse

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Dave Dolson <[email-masked]>
Date: Fri, 1 Jul 2016 17:10:55 +0000

Maryse,
OK, I understand your question.

Reading 3GPP 23.003, IMEI and IMEISV are clearly defined as 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 for the international mobile equipment identifier and software version according to 3GPP TS 23.003."

It seems reasonable to extend to a Type 4 for IMEI, but there does not seem to have been a need, or there would have been an IANA allocation (which does not require RFC revision).

Perhaps you could explain the need to the group?

-Dave

-----Original Message-----
From: Gardella, Maryse (Nokia - FR) [mailto:[email-masked]] 
Sent: Friday, July 01, 2016 9:02 AM
To: Dave Dolson; [email-masked]
Subject: RE: [Dime] RFC 4006 bis - IMEI

Hi Dave,

BR
Maryse

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: jeudi 30 juin 2016 19:39
To: Gardella, Maryse (Nokia - FR); [email-masked]
Subject: Re: [Dime] RFC 4006 bis - IMEI

Maryse,

-Dave

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Gardella, Maryse (Nokia - FR)
Sent: Thursday, June 30, 2016 12:59 PM
To: [email-masked]
Subject: [Dime] RFC 4006 bis - IMEI

All,

  
 IMEISV                          0

IMEI(SV)                          0

BR
Maryse

---

From: "Gardella, Maryse (Nokia - FR)" <[email-masked]>
Date: Tue, 5 Jul 2016 13:16:19 +0000

Hi Dave, 

Do you mean, in case this new value would be needed, it is possible to handle this via IANA allocation w/o impacting existing RFC 4006? Could you clarify this for me?

Thanks
Maryse 

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: vendredi 1 juillet 2016 19:11
To: Gardella, Maryse (Nokia - FR); [email-masked]
Subject: Re: [Dime] RFC 4006 bis - IMEI

Maryse,

-Dave

-----Original Message-----
From: Gardella, Maryse (Nokia - FR) [mailto:[email-masked]] 
Sent: Friday, July 01, 2016 9:02 AM
To: Dave Dolson; [email-masked]
Subject: RE: [Dime] RFC 4006 bis - IMEI

Hi Dave,

BR
Maryse

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: jeudi 30 juin 2016 19:39
To: Gardella, Maryse (Nokia - FR); [email-masked]
Subject: Re: [Dime] RFC 4006 bis - IMEI

Maryse,

-Dave

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Gardella, Maryse (Nokia - FR)
Sent: Thursday, June 30, 2016 12:59 PM
To: [email-masked]
Subject: [Dime] RFC 4006 bis - IMEI

All,

  
 IMEISV                          0

IMEI(SV)                          0

BR
Maryse

---

From: Dave Dolson <[email-masked]>
Date: Tue, 5 Jul 2016 15:31:30 +0000

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 first step would be to begin a thread on the dime mailing list to request the 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) [mailto:[email-masked]] 
Sent: Tuesday, July 05, 2016 9:16 AM
To: Dave Dolson; [email-masked]
Subject: RE: [Dime] RFC 4006 bis - IMEI

Hi Dave, 

Thanks
Maryse 

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: vendredi 1 juillet 2016 19:11
To: Gardella, Maryse (Nokia - FR); [email-masked]
Subject: Re: [Dime] RFC 4006 bis - IMEI

Maryse,

-Dave

-----Original Message-----
From: Gardella, Maryse (Nokia - FR) [mailto:[email-masked]] 
Sent: Friday, July 01, 2016 9:02 AM
To: Dave Dolson; [email-masked]
Subject: RE: [Dime] RFC 4006 bis - IMEI

Hi Dave,

BR
Maryse

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: jeudi 30 juin 2016 19:39
To: Gardella, Maryse (Nokia - FR); [email-masked]
Subject: Re: [Dime] RFC 4006 bis - IMEI

Maryse,

-Dave

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Gardella, Maryse (Nokia - FR)
Sent: Thursday, June 30, 2016 12:59 PM
To: [email-masked]
Subject: [Dime] RFC 4006 bis - IMEI

All,

  
 IMEISV                          0

IMEI(SV)                          0

BR
Maryse

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 5 Jul 2016 09:32:02 -0700

Designated experts would most likely be either Lionel or me. Basically 
the procedure goes like: there's a public spec (no need to be in IETF) 
or at least technical discussion (preferably in IETF) of the allocation 
need of the new code point, and once that is "done" someone does a 
request to IANA. Then IANA will contact the "expert", who evaluates the 
allocation requests and either grants or denies it. The more information 
there is available for the allocation requests the more comfortble the 
expert is backing up the request towards IANA.

For example various 3GPP CT group secretaries have done allocation 
requests to IANA during years.

Regarding the User-Equipment-Info-Type AVP doing the new allocation 
doing it in RFC4006bis would be "easy".. assuming we finish this 
discussion into an agreement for a need.

- Jouni

---

From: <[email-masked]>
Date: Tue, 5 Jul 2016 17:09:29 +0000

For clarification, for Diameter related IANA allocation requests, it is under the responsibility of CT4 secretary.

Now, as said by Dave and Jouni, we should clarify the requirement for an IMEI specific value whereas only the IMEISV is actually used.

Regards,

Lionel

> -----Message d'origine-----
> De : DiME [mailto:[email-masked]] De la part de Jouni Korhonen
> Envoyé : mardi 5 juillet 2016 18:32
> À : Dave Dolson; Gardella, Maryse (Nokia - FR); [email-masked]
> Objet : Re: [Dime] RFC 4006 bis - IMEI
> 
> Designated experts would most likely be either Lionel or me. Basically the
> procedure goes like: there's a public spec (no need to be in IETF) or at least
> technical discussion (preferably in IETF) of the allocation need of the new code
> point, and once that is "done" someone does a request to IANA. Then IANA will
> contact the "expert", who evaluates the allocation requests and either grants or
> denies it. The more information there is available for the allocation requests the
> more comfortble the expert is backing up the request towards IANA.
> 
> For example various 3GPP CT group secretaries have done allocation requests to
> IANA during years.
> 
> Regarding the User-Equipment-Info-Type AVP doing the new allocation doing it
> in RFC4006bis would be "easy".. assuming we finish this discussion into an
> agreement for a need.
> 
> - Jouni
> 
> > 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 first step
> would be to begin a thread on the dime mailing list to request the new
> allocation, justifying why it is needed.
> >
> > Do you mean, in case this new value would be needed, it is possible to handle
> this via IANA allocation w/o impacting existing RFC 4006? Could you clarify this
> for me?
> >
> > Thanks
> > Maryse
> >
> > Also, the most recent 3GPP 32.299 indicates "The used value is 0 for the
> international mobile equipment identifier and software version according to
> 3GPP TS 23.003."
> >
> > It seems reasonable to extend to a Type 4 for IMEI, but there does not seem
> to have been a need, or there would have been an IANA allocation (which does
> not require RFC revision).
> >
> > Otherwise if a new value is needed for this distinction, I would
> > propose the User-Equipment-Info-Type AVP to be extended with IMEI
> > value
> >
> >
> > BR
> > Maryse
> >
> > Is there precedent for the overloading you propose, such as a 3GPP standard
> or de facto standard usage that you can cite?
> >
> > As part of the updates to RFC 4006 I propose to consider the IMEI also when
> refering to IMEISV, otherwise it is not clear if User-Equipment-Info-Type value O
> can be used for IMEI.
> >
> >

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information 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 delete 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.

---

From: Yuval Lifshitz <[email-masked]>
Date: Wed, 6 Jul 2016 10:41:22 +0000

* In 3GPP TS 29.061 they use the AVP length to differentiate IMEI from IMEISV in the RADIUS AVP
* In 3GPP TS 29.060 (GTP-C) they pad with ones in case that the software version is not there

So, my guess is that the gateway is probably using one of the above options in when sending the value over Diameter. So, it is probably safe to assume that the IMEISV enum is used to send both types of data.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, July 05, 2016 8:09 PM
To: [email-masked]; Dave Dolson; Gardella, Maryse (Nokia - FR); [email-masked]
Subject: Re: [Dime] RFC 4006 bis - IMEI

Regards,

Lionel

> Envoyé : mardi 5 juillet 2016 18:32 À : Dave Dolson; Gardella, Maryse 
> (Nokia - FR); [email-masked] Objet : Re: [Dime] RFC 4006 bis - IMEI
> 
> or at least technical discussion (preferably in IETF) of the 
> allocation need of the new code point, and once that is "done" someone 
> does a request to IANA. Then IANA will contact the "expert", who 
> evaluates the allocation requests and either grants or denies it. The 
> more information there is available for the allocation requests the more comfortble the expert is backing up the request towards IANA.
> 
> this via IANA allocation w/o impacting existing RFC 4006? Could you 
> clarify this for me?
> >
> > Thanks
> > Maryse
> >
> > Reading 3GPP 23.003, IMEI and IMEISV are clearly defined as 
> > different things
> in sections 6.2.1 and 6.2.2.
> international mobile equipment identifier and software version 
> according to 3GPP TS 23.003."
> >
> to have been a need, or there would have been an IANA allocation 
> (which does not require RFC revision).
> >
> > Indeed it was not clear to me whether the current definition 
> > explicitly excluded
> the IMEI or not.
> > I was wondering about the behavior of the client in case the 
> > Software Version
> Number (SVN) is not available.
> >
> > If I understand correctly, you are proposing overloading a type, 
> > distinguishing
> the types only by length.
> >
> > Otherwise, IANA may assign new values for new types, and we aren't 
> > short on
> space:
> > http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml#
> > aa
> > a-parameters-41
> >
> >
> > -Dave
> >
> >
> >
> refering to IMEISV, otherwise it is not clear if 
> User-Equipment-Info-Type value O can be used for IMEI.
> >
> >
> > In section 8.50. User-Equipment-Info-Type AVP in RFC4006,the 
> > following is
> specified:
> >
> >  IMEISV                          0
> > 	or the International Mobile Equipment Identifier in the 
> > international
> IMEI format
> > Differentiation between IMEI (15 digits) and IMEISV (16 digits) is 
> > based on AVP
> length, would this work?
> >
> > BR
> > Maryse
> >

Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information 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 delete 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.

---

From: <[email-masked]>
Date: Wed, 6 Jul 2016 12:38:53 +0000

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 in the TS 23.003, defined as two distinct identifiers:
IMEI     = TAC | SNR |CD/SD
                  8-D    6-D     1-D

IMEISV = TAC | SNR | SVN
                  8-D    6-D     2-D

On some 3GPP interfaces, these Ids are conveyed into two different 3GPP-specific 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 same AVP two values with two different semantics.

regards,

Lionel

> De : Yuval Lifshitz [mailto:[email-masked]]
> Envoyé : mercredi 6 juillet 2016 12:41
> À : MORAND Lionel IMT/OLN; [email-masked]; Dave Dolson;
> Gardella, Maryse (Nokia - FR); [email-masked]
> Cc : Yuval Lifshitz
> Objet : RE: [Dime] RFC 4006 bis - IMEI
> 
> So, my guess is that the gateway is probably using one of the above options in
> when sending the value over Diameter. So, it is probably safe to assume that the
> IMEISV enum is used to send both types of data.
> 
> Now, as said by Dave and Jouni, we should clarify the requirement for an IMEI
> specific value whereas only the IMEISV is actually used.
> 
> Regards,
> 
> Lionel
> 
> > more information there is available for the allocation requests the more
> comfortble the expert is backing up the request towards IANA.
> >
> _________________________________________________________________
> ________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles 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. Les messages
> electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed, used
> or copied without authorisation.

---

From: Yuval Lifshitz <[email-masked]>
Date: Wed, 6 Jul 2016 14:58:03 +0000

Having two codes is surely better. 
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 probably overloaded in the Diameter AVP when type is IMEISV.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 06, 2016 3:39 PM
To: Yuval Lifshitz; [email-masked]; Dave Dolson; Gardella, Maryse (Nokia - FR); [email-masked]
Subject: RE: [Dime] RFC 4006 bis - IMEI

IMEISV = TAC | SNR | SVN
                  8-D    6-D     2-D

regards,

Lionel

> De : Yuval Lifshitz [mailto:[email-masked]] Envoyé : mercredi 
> 6 juillet 2016 12:41 À : MORAND Lionel IMT/OLN; 
> [email-masked]; Dave Dolson; Gardella, Maryse (Nokia - FR); 
> [email-masked] Cc : Yuval Lifshitz Objet : RE: [Dime] RFC 4006 bis - 
> IMEI
> 
> So, my guess is that the gateway is probably using one of the above 
> options in when sending the value over Diameter. So, it is probably 
> safe to assume that the IMEISV enum is used to send both types of data.
> 
> For clarification, for Diameter related IANA allocation requests, it 
> is under the responsibility of CT4 secretary.
> 
> Now, as said by Dave and Jouni, we should clarify the requirement for 
> an IMEI specific value whereas only the IMEISV is actually used.
> 
> Regards,
> 
> Lionel
> 
> > De : DiME [mailto:[email-masked]] De la part de Jouni 
> > Korhonen Envoyé : mardi 5 juillet 2016 18:32 À : Dave Dolson; 
> > Gardella, Maryse (Nokia - FR); [email-masked] Objet : Re: [Dime] RFC 
> > 4006 bis - IMEI
> >
> > Designated experts would most likely be either Lionel or me. 
> > Basically the procedure goes like: there's a public spec (no need to 
> > be in IETF) or at least technical discussion (preferably in IETF) of 
> > the allocation need of the new code point, and once that is "done" 
> > someone does a request to IANA. Then IANA will contact the "expert", 
> > who evaluates the allocation requests and either grants or denies 
> > it. The more information there is available for the allocation 
> > requests the more
> > would be to begin a thread on the dime mailing list to request the 
> > new allocation, justifying why it is needed.
> > >
> confidentielles 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. Les messages electroniques etant susceptibles 
> d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.