Re: [Dime] RFC 4006 bis - IMEI

Jouni Korhonen <jouni.nospam@gmail.com> Tue, 05 July 2016 16:32 UTC

Return-Path: <jouni.nospam@gmail.com>
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 6492912D5CA for <dime@ietfa.amsl.com>; Tue, 5 Jul 2016 09:32:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 gG1RT8cm-ULd for <dime@ietfa.amsl.com>; Tue, 5 Jul 2016 09:32:16 -0700 (PDT)
Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73D2A12B04E for <dime@ietf.org>; Tue, 5 Jul 2016 09:32:15 -0700 (PDT)
Received: by mail-pa0-x230.google.com with SMTP id uj8so8952646pab.3 for <dime@ietf.org>; Tue, 05 Jul 2016 09:32:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=J8ovBcdeRCeGN7XdECKBT1iWSfCMrZ8EKDxuP9+CyZY=; b=KR0yaYN3xn71TN9yeiHv5uD1seexkKT+2mPiElXkj0sUkBwF77KULR+Qz+OB3vAh0j OADEG/6JYPC+YAYalghcVk/IzlDo4nh8DXWeTNQIlJCHVQOcPMcuXw2R/EBaJezVu2Em aRcGtsLhVS6qq6c3WAF1zRDeFbZ9cWoDFOEu2rcLotpMuF5FDUM6gjalpIL45Ad+ePqm eQWhwXkg+1qmKe4kFcgv97Bw1m54tb/Om8YuWotyl5XkW5h39NelToiPdSf7/q7GMtFk Lc4dhFfTtBA7PY5jCK73yu5hHk9FcRGB+TIK0/f+dENdX+DbWKNK/VIlbBFNCr20LK08 UJmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=J8ovBcdeRCeGN7XdECKBT1iWSfCMrZ8EKDxuP9+CyZY=; b=WVyWBLfVXgQrqcTuvwIRUS4NXhWTnOif4TU02fqI6R/+SvqYBFwjPAs0l00UOJrply YEhB+y6Rl8o/TZ8xF/hAak1oTPJIzEE9U/9BYvTP8Vs383K3tMX3S91J9KrTPf/AhY2e MgmE6pFLxbnJ226CYsHGxhjnxUTw8CDODy9qy7wyzOJeOMfTxfuOsAVwnHSAQEazBOZb pT0qLUC4PXvOIHjOb0f9Mpn4iMnzGDUS4GUkvqYSUxDEADX5oCmZEzNTrGF8NKw74W+A tvzTau4vJKFjjQ2f9JzNAJjIyvNAkFaWPB6HCBpvN6hmMV7DN0UN4CEV/vwFDgie5JAm opGw==
X-Gm-Message-State: ALyK8tI+lxV9e1gizBi/RfnxyCu5KrHAhqjB8QbRsz+aU4xGWGnf3NhJ2SmGZZLqhhatCA==
X-Received: by 10.66.248.3 with SMTP id yi3mr33588547pac.61.1467736334757; Tue, 05 Jul 2016 09:32:14 -0700 (PDT)
Received: from [10.16.65.14] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id by5sm6464781pad.36.2016.07.05.09.32.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jul 2016 09:32:14 -0700 (PDT)
References: <F77ED24D51A356439EE433AD28B990DFC50E75CA@FR712WXCHMBA09.zeu.alcatel-lucent.com> <E8355113905631478EFF04F5AA706E9830FDB614@wtl-exchp-2.sandvine.com> <F77ED24D51A356439EE433AD28B990DFC50E7E36@FR712WXCHMBA09.zeu.alcatel-lucent.com> <E8355113905631478EFF04F5AA706E9830FDCF7C@wtl-exchp-2.sandvine.com> <F77ED24D51A356439EE433AD28B990DFC50E9969@FR712WXCHMBA09.zeu.alcatel-lucent.com> <E8355113905631478EFF04F5AA706E9830FE4A5B@wtl-exchp-2.sandvine.com>
To: Dave Dolson <ddolson@sandvine.com>, "Gardella, Maryse (Nokia - FR)" <maryse.gardella@nokia.com>, "dime@ietf.org" <dime@ietf.org>
From: Jouni Korhonen <jouni.nospam@gmail.com>
Message-ID: <e9b91f39-ad3f-4224-0e5e-ff1b8048e23d@gmail.com>
Date: Tue, 05 Jul 2016 09:32:02 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <E8355113905631478EFF04F5AA706E9830FE4A5B@wtl-exchp-2.sandvine.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/rY119nmjLFOfndq8aEnWOo0xuHY>
Subject: Re: [Dime] RFC 4006 bis - IMEI
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: jouni.nospam@gmail.com
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jul 2016 16:32:18 -0000

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

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 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: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 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: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 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: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 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: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, 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:dime-bounces@ietf.org] On Behalf Of Gardella, 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 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
> 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
>