Re: [lp-wan] lpwan-overview comments

[Stephen Farrell <[e-mail]>]

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]
> https://www.ietf.org/mailman/listinfo/lp-wan
>