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

[john.loughney@nokia.com]

Hi Alper,

> > 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...

Well, technically, there is no layer called GPRS.  I guess it would be better
to call it a PDP-context - this is the actual layer below IP.  If helpful,
I can suggest text.
 
> > 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 someother
> > issues with IPv6.
> 
> We shall fix that.

Good.
 
> > 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.

Good.
 
> > 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.

Good.
 
> > 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...

Well, I guess there is an 802.21 presentation in the session, so I'll hold off any
comments.
 
> > 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?

Let me review, and I think I can suggest text, I will send it.

John