RE: [DNA] RE: Review of link-information from Pekka Savola

[jouni.korhonen@teliasonera.com]

Hi,

Some comments on the 3GPP part of this draft. I think the
text should also mention that the PDP context creation can
be network originated. Also at least since Release-99 it has
been possible to create secondary PDP contexts and more than
one primary PDP context. IMO those should be addresses.

In the case of secondary PDP context creation the MT has been
configured with a functional IP address (including the IPv6 case).
The IP address of the primary PDP context is assigned to
secondary contexts.

For additional primary PDP contexts the MT is assigned a new
additional IP address. Thus it is possible to receive link-up
notification while already being able to send/receive IP packets
through existing PDP contexts. Also vice versa for link-down
notifications.

Of course if the draft will not address anything beyond release-98
then the above notes are mostly insignificant (excluding the network
initiated PDP context creation).

Cheers,
	Jouni

> -----Original Message-----
> From: owner-dna@ecselists.eng.monash.edu.au 
> [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of 
> Alper Yegin
> Sent: 29. huhtikuuta 2005 2:29
> To: 'Greg Daley'; dna@eng.monash.edu.au
> Cc: pekkas@netcore.fi
> Subject: [DNA] RE: Review of link-information from Pekka Savola
> 
> 
> Thanks Pekka.... 
> My response is inlined below...
>  
> >  1. 3GPP/3GPP2 network architecture discussion is very 
> useful for the  
> > uninitiated, but hopefully it has been reviewed by 3GPP/3GPP2 folks 
> > that  it's correct so that there's no need to iterate over it later?
> 
> Co-authors who contributed to the respective sections are 
> involved with
> 3GPP/2 work. But of course, we wouldn't mind more reviews. We 
> can seek out further 3G* reviews at the latest during the WG LC.
> 
> >  2. The document's category and the approach is not clear.  The
> charter
> >  says Informational, but the document has MUST keywords (in an  
> > inconsistant manner; some link layers use uppercase, some don't).
> >  This needs to be rethought.  I personally don't have a big 
> problem  
> > with upper keywords in non-Standards track document, but in 
> case they  
> > are here, they should be used consistently and well.  There are also
> a
> >  few "shoulds" which should probably be musts or the like.
> 
> OK, we'll go over them and make them all uppercase. 
> 
> >  3. Does 802.1x change the situation with WiFi or wired ethernet?
> 
> IEEE 802.11i discussion covers that for WiFi. Ethernet text 
> is not included in the I-D yet.
> 
> >  4. Discussion of wired Ethernet would be extermely useful...
> 
> Yes, I agree. We'll be incorporating Greg's text for that.
> 
>  
> >  5. Some implementations may also support more extensive 
> notifications 
> > (e.g.,  about the signal strength).  Are these explicitly 
> out of scope 
> > (might make  sense, but might also make sense to state that 
> > explicitly) ?
> 
> They are explicitly outside the scope of DNA. 
> 
>    The document limits itself to the minimum set of 
> information that is
>    necessary for solving the DNA problem [I-D.ietf-dna-goals].  A
>    broader set of information may be used for other problem spaces
>    (e.g., anticipation-based Mobile IP fast handovers
>    [I-D.ietf-mobileip-lowlatency-handoffs-v4]
>    [I-D.ietf-mipshop-fast-mipv6]).  Separate documents that are
>    backward-compatible with this one can be generated to 
> discuss further
>    enhancements.
> 
> The above text meant to capture that. We can add explicit 
> examples like yours to make it clearer.
> 
> 
> >  semi-editorial
> >  --------------
> > 
> >      Node's establishment of a link-layer connection with an
> attachment
> >      point that signifies the availability of IP service 
> (i.e., being 
> > able
> >      to send and receive IP packets) between the two is 
> considered a 
> > link
> >      up event.
> > 
> >  ==> a physical link is a link which can carry any media.  
> Maybe you 
> > should  reword this slightly -- for example, a host does not know 
> > about availability  of IP (or anything else).  Maybe 
> "availability of 
> > IP service" is specific to  some link types which can only carry IP 
> > service, not any L3 protocol?
> 
> Not sure if I understood this. Could you please elaborate a bit more? 
> 
> >  4.  Security Considerations
> > 
> >      A faked link-layer event notification can be used to launch a
> >      denial-of service attack on the node and the 
> associated network.
> >      Secure generation and delivery of these notifications must be
> >      ensured.  This is a subject for link-layer and network stack 
> > designs
> >      and therefore it is outside the scope of this document.
> > 
> >  ==> this may call for a bit more analysis.  Who can forge those 
> > link-layer  notifications?
> 
> We are not getting into these details in the text, but... in 
> some technologies remote nodes may be able to forge them.
> 
> > The stack itself?  
> 
> Sure, the stack can too. But this is uninteresting. I mean, 
> if the stack below is not trustworthy, what can you do?
> 
> > Can someone else (e.g., a
> > Disassociate L2
> >  message)?  Is there more than shooting yourself in the foot here?
> 
> Imo, once L2 tells L3 that the link is up or down, there is 
> not much for
> L3 to do but believe it. 
> 
> >  editorial
> >  ----------
> 
> We'll take care of the editorials.
> 
> Thanks again.
> 
> Alper
> 
> 
>