RE: [DNA] question on draft-ietf-dna-link-information-01.txt

[Alper Yegin <alper.yegin@samsung.com>]

Hi John,

Thank you for your review and feedback.

> In Section 2.1  GPRS/3GPP, it is not clear if you are talking about
GSM,
> UMTS or what.
> GPRS can be applied to both the GSM & UMTS air interfaces, as GPRS is
more
> of
> a networking technology.  It might make more sense to discuss GSM/UMTS
> when
> discussing the air interface and GPRS when discussing the networking
> technology
> (SGSN, GGSN).  

If GPRS is the layer one below IP and commonly used for both GSM and
UMTS, wouldn't it be better just to talk about that? Are there any
specifics of GSM and UMTS we should be reflecting to the text? I'm not
too familiar with the 3GPP stack, I might be missing something...

> Also, its not clear if the section is talking about IPv4 or
> IPv6.
> If it is talking about IPv4, then I think there are a number of
> inaccuracies,
> such as:
> 
>    ... It is only after the
>    PDP Context has been established, address autoconfiguration and
>    tunneling mechanism have taken place that the MT's IP packets can
be
>    forwarded to and from its remote IP peers.
> 
> Address autoconfiguration doesn't apply to IPv4.  Also, there are some
> other
> issues with IPv6.

We shall fix that.

> In general, I think the main points of the section should be:
> 
>    The successful establishment of a PDP Context on a GPRS indicates a
>    link-up event. A PDP Context deactivation indicates a link down
event
>    notification.

Absolutely.

> Section 2.2 covers 3GPP2 air interfaces & networks somewhat better,
but
> I think a more rigorous seperation between the air interface and
> network side would be good.
> 
> Also, just to confuse things, both 3GPP and 3GPP2 networks are
supporting
> WLAN access, so ultimately, we may like to restrict these sections
more
> to the air interface than the SDO.

Good point.

> Is there any consideration about mentioning 802.21? This is, of
course, a
> work in
> progress, but I would suggest that it at least be metioned, as it is
> relevant here.

I'm interested in understanding the relevance. Further elaboration is
welcome...

> Finally, I find section 4.  Security Considerations rather inadequate.
I
> would
> prefer a concise mention about the DoS attacks possible based upon
link-
> events,
> and perhaps state that any link indication should not necessarily be
> considered
> authorative by itself.  A mobile node should probably make the final
> decision
> about whether a link is down or up.  There may be additional
indications
> that the mobile terminal would include before marking a link as up or
> down.

This one we had discussed before and I still cannot see what we can do
in this document. L2 event notifications are coming from the L2 on the
same stack. If your L2 has believed something (signal strength, etc.)
and performed a handover, and just notifying your L3 about that, what
can the event notification consumer do? Just believe it... This is just
a notification of an event that already took place. I don't see L3
questioning L2's decision. What do you think?

Alper