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

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

John,

Thank you. Suggested text, as always, is very welcome.

Alper



> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Sunday, March 06, 2005 2:48 PM
> To: alper.yegin@samsung.com; dna@eng.monash.edu.au
> Subject: RE: [DNA] question on draft-ietf-dna-link-information-01.txt
> 
> 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