Re: [lp-wan] lpwan-overview comments

[Alper Yegin <[e-mail]>]

Hi Stephen,

> I suspect this is one of those where we'll only understand
> one another f2f, but…

One more try over email. If still not clear, we can chat over the phone. I won’t be at IETF this time unfortunately.


When confronted by a Join-request, the NS needs to figure out how to authenticate the request.
If the NS can recognize the DevEUI, then it’d know how to do the auth (e.g., by locally, or by forwarding to an external JS for that given DevEUI entry).
If the NS cannot recognize the DevEUI, then it resorts to AppEUI (or JoinEUI, both are different names for the exact same field in the Join-Request — name change happening in revisions). AppEUI/JoinEUI tells the NS who can authenticate that request (a local/co-located JS, or an external JS identified by the AppEUI/JoinEUI).

The confusion is arising from the evolving name and semantics of that field.

At any rate, LW1.0.2 says: 

"The AppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies the entity able to process the JoinReq frame."

In my emails I’ve been highlighting the essential/underlined role of the AppEUI field. 




Alper















> On Jul 1, 2017, at 10:40 PM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> Hiya,
> 
> I suspect this is one of those where we'll only understand
> one another f2f, but...
> 
> On 01/07/17 20:18, Alper Yegin wrote:
>> Hi Stephen,
>> 
>>>> 
>>>> 
>>>>  End-devices are assumed to work with one or a quite limited number of
>>>>  applications, identified by a 64-bit AppEUI, which is assumed to be a
>>>>  registered IEEE EUI64 value.
>>>> 
>>>> 
>>>> 
>>>> AppEUI is being renamed as JoinEUI in LoRaWAN 1.1, and in fact it identifies the JS.
>>>> JoinEUI and JS terms are not present in LW1.0.x, but nevertheless the latest definition of the AppEUI in LW1.0.2 is as follows:
>>>> 
>>>> 
>>>> 
>>>> The AppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies
>>>> 
>>>> the entity able to process the JoinReq frame.
>>>> 
>>>> 
>>>> So, we better not treat it as application identifier, but as identifier of the entity that can authenticate the Join-request frames.
>>>> 
>>>> For example, instead of:
>>>> 
>>>> AppEUI	IEEE EUI64 naming the application
>>>> 
>>>> We better say:
>>>> 
>>>> AppEUI	IEEE EUI64 naming the entity that processes Join-request
>>> 
>>> So I just don't understand how that can be correct, sorry;-)
>>> 
>>> A join-request is processed by a NS (or, in 1.1 a JS). There are very
>>> few of those, maybe 1 per n/w. There are many more device-types, which
>>> do mostly map 1:1 with AppEUIs. And the same device-types can be found
>>> in many networks.
>>> 
>>> So the suggested text just seems incorrect to me.
>>> 
>>> I'd say we're better to just stick with 1.0.2 terms tbh.
>>> 
>> 
>> If we want to strictly  stick with the LW1.0.2 definition, than it’d be:
>> 
>> AppEUI	IEEE EUI64 application id that identifies the entity processesing Join-request
>> 
> 
> Just to note: the above doesn't help me. I read it as the same as
> your previous suggested text, and hence, for me, it just reads like
> a false statement. (I don't mean badly worded, I mean untrue:-)
> 
>> In practice, it identifies the JS.
> 
> Let me try explain why I don't get that.
> 
> Each instance of some class of device will have the same AppEUI,
> call that "X." Let's say there are 10^5 instances of devices
> like that.
> 
> Let's say there are 2 LoRaWAN networks, each with an NS that has
> a co-located NS. With half the "X" type devices in each.
> 
> Both networks (call them N1, N2) have devices of the type that
> uses AppEUI X.
> 
> There is a 5000:1 ratio between instances of X and NS's/JS's
> in each network.
> 
> X therefore does not identify an NS or JS or anything like that.
> 
> Do you see why I'm confused if you want to say that X identifies
> or names the JS?
> 
> Cheers,
> S.
> 
>> 
>> Note that:
>> - NS and JS may be co-located or separated. This is true for both LW1.0.x and LW1.1 specs.
>> - The entity that processes the Join-request and generates Join-accept is the JS.
>> - Single NS may be connected to multiple JSs.
>> - Spec is based on 1:1 relationship between the end-device and JS. (Obviously, implementations can extend that).
>> - If the NS knows the identify of the JS to process an incoming Join-request based on the DevEUI, then AppEUI (which is later renamed to JoinEUI in LW1.1) has no significance. Otherwise, the NS relies on the AppEUI (JoinEUI) to identify the JS to process the request.
>> 
>> I just elaborated on these details, not to suggest including in the draft, but to point out that the significance of the AppEUI is to “ identify(ies) the entity able to process the JoinReq frame.” as stated in the LW1.0.2 spec. As long as we capture that, it is OK if the draft also refers to it as “application id”. (The reason name of the Join-request field morphed from AppEUI into JoniEUI in LW1.1 is basically this.)
>> 
>> Regards,
>> 
>> Alper
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> Cheers,
>>> S.
>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Thanks Stephen.
>>>> 
>>>> Alper
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> lp-wan mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/lp-wan
>>>> 
>>> 
>> 
>> _______________________________________________
>> lp-wan mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/lp-wan <https://www.ietf.org/mailman/listinfo/lp-wan>