Re: [lp-wan] lpwan-overview comments

[Stephen Farrell <[e-mail]>]

Hi Alper,

Sorry for the slow response, but I'm doing edits on this now so...

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
> 
> In practice, it identifies the JS.

So my issue with saying that is that one JS will like be the JS
for many AppEUIs so it's an N:1 mapping between AppEUI and JS
identifiers (be those IP addresses or names), so saying that an
AppEUI "identifies" a JS seems wrong to me still.

Would it work for you if we say it like this:

"
AppEUI: IEEE EUI64 corresponding to the join server for an application
"

That also calls for a definition of the JS I guess, so I can
also add:

- Join Server: The Join Server (JS) is a server on the Internet
side of an NS that processes join requests from end-devices.

Cheers,
S.

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
>