Subject: [mobile-ip] 3g wireless extentions draft - feedback from IESG

From: Phil Roberts <[email-masked]>
Date: Mon, 27 Aug 2001 10:01:58 -0400

Hi folks,

   here is the complete feedback from the IESG on this document.
Ying has already seen some of it and made some editorial updates, but the
document is receiving serious scrutiny as you can see from the
first three paragraphs.  The IESG is trying to determine what
exactly to do with this document.

   What we've decided to do as a working group is to forward this
as an Informational RFC from the WG.  Should we continue this course?
If so, are the suggested changes agreeable?

Alternatives would be to publish this as an individual contribution
for an Informational RFC if it is agreed that although this reuses
Mobile IP messages it has little to do with Mobile IP otherwise and
is of very limited application, or to realize that the spec is
published elsewhere (in the cdma2000 standards suite) and there is
little purpose of having the IETF publish such a doc.

Phil

--------------------------------

General: does this document really need to be published as an RFC? It
seems to be addressing a narrow problem that is of little interest to
most MIP implementations. It is also a rather ugly solution, one that
I suspect the MIP WG had no input on. Was this presented as a
completed document before it was made a WG document?

Also, why isn't this a Standards Track document? I suspect the answer
is because it is really not a modification of MIP supported by the
WG. Rather it is documenting something 3GPP2 did, but that cannot be
changed at this point. Is this the case? If so, I could see publishing
this as an informationl RFC, but only if it is modified as outlined
below.

Has this document already been published elsewhere? If so, does it
need to be published as an RFC as well?

>          Mobile IP Based Micro Mobility Management Protocol in 
>                  The Third Generation Wireless Network 

Change title to make clear that this applies only to cdma2000
networks. 

Indeed, based on comments below, it might be good to also change the
title to not suggest that this is some sort of general purpose MIP
protocol. It is clearly not.

Too many authors listed on page one. Please move list of authors to
acknowledgment section and only list the editor on the first page.

Add a paragraph or two that provide context for why this is being
published, and how it relates to MIP. In particular, this uses
different UDP ports than MIP (so would not seem to be MIP at all!). In
other words, an applicability statement of sorts, to make it clear
that this is of limited interest to most folks.

Finally, calling this an extension to MIP is somewhat of a
stretch. For starters, it uses a different UDP port number. That alone
would make it a different protocol in most people's eyes. This is a
rather ugly hack, IMO. It uses a different port number, yet uses many
of the same MIP message types, though augmented in some cases. To make
matters worse, it appears to use (for example) apparently unused bits
in existing MIP messages (i.e, the 'r' and 'x' bits in Registration
Requests). 2002-bis says for the 'r' bit:

>      r        Sent as zero; ignored on reception.  SHOULD NOT be
>               allocated for any other uses.

So its clearly infringing on MIP as well.

One *could* make the argument that because this document uses a
different port number, MIP doesn't need to assign the code points that
are implied here. There should be no conflict since MIP messages go to
the MIP port, and the messages in this document go to a different
port. But I would guess that this would cause problems for some
existing implementations that have not made a clean distinction
between MIP proper, and the extensions defined in this document . :-(

>    Mobile IP requires link layer connectivity between the Mobile Node 
>    and the Foreign Agent. This draft proposes a protocol for achieving 
>    this when the physical layer terminates at a point distant from the 
>    FA. In particular, this protocol applies to cdma2000 networks where 
> 

Might help to point out that this is all done transparently to the
client/mobile node, and is something that is done between the RNN and
FA. This is a key point, as it means the document is probably not of
relevance to most MIP implementations.

Also, the wording doesn't really seem right. Does this draft really
"propose a protocol for achieving" ... link-layer connectivity between
the MN and FA? Can one run ARP when this protocol is employed? Can one
send arbitrary L2 packets? Or is it in fact limited to tunneling IP
packets?

>    The interface between the RNN and the PDSN is called the RP 
>    interface. This interface requires mobility management for handling 
>    handoff from one RNN to another without interrupting end to end 
>    communication. It also requires the support of the link layer 
>    protocol encapsulation.  

Is "interface" the right terminology here? Seems like if the RNN and
PDSN are in separate boxes, this is a "protocol". Is this a
terminology mismatch between the IETF and 3GPP2?

>    This document defines extensions to the Mobile IP protocol [1] to 
>    allow mobility management for the interface between a radio network 
>    and a packet data network in the third generation cdma2000 network.  

Again, I find the terminology "interface" here to be confusing.

Also, I think it is misleading to call this "extensions to Mobile
IP". It isn't really extending what most people think of MIP (i.e, the
MN-HA-CN interactions). It is defining something specific that allows
the FA to not have to reside on the directly attached link. It might
be good to define some generic terminology that makes this more clear
at the start of the document. For an analogy, in PPP, the client dials
directily into the NAS and the NAS and PPP server are on the same
device. L2TP allows the NAS/PPP server functionality to be split into
two distinct parts, connected by a network. That is, the NAS tunnels
stuff to the PPP server (transparently from the client's
perspective). This seems to be a analagous type of thing (though the
details are of course very different).

>    The messages used for mobility management across the RP interface 
>    include Registration Request, Registration Reply, Registration 
>    Update and Registration Acknowledge. Both Registration Request and 
>    Registration Update messages MUST be sent with UDP using well-known 
>    port number 699. 

Rather than using terminology such as "used for mobility management",
say "used for tunneling MIP messages" ... Personally, I find the term
"mobility management" to be almost meaningless. Seems like it could
mean anything to anyone.

Interestingly, Figure one shows a HA, but no FA. Yet all the previous
text talks about the FA, and not a HA.  Is this document about FA
intereactions , HA interactions, or both? This could be clarified.

The reuse of the mobile IP messages causes terminology confusion.
Those messages have terms like home address, home agent address, CoA, etc
which are meaningful in the MIP context.
This prototocol operates between a MIP MN and a MIP FA thus to be clear
it would make sense to actually replace the terminology used to describe the
message formats as follows:
Current			Actual
Home Address		Must be zero
Home Agent		PDSN address (which is a MIP FA)
Care of Address		RNN address

If those terminology changes are made then it is possible to describe
the interaction between the RP protocol and MIP without causing utter
confusion.

> 4.1 Registration Request 
>     
>    In a cdma2000 network, the mobile node initiates a connection by 
>    sending a call setup indication to the RNN across the radio network. 

What kind of setup? to HA, FA, or either? Or is this an L2 connection?

There are some formatting problems with the picture in 4.2 (tabs?).

> 6.0 IANA Considerations 
>
>    The recommended message type value and extension type value have 
>    been used in 3GPP2 standard IOSv4.1. It is desirable to have the 
>    same type value assigned by IANA. 

This is really unfortunate. It appears that IANA was never consulted
about the use of some of these numbers; they were just used. This is
wrong. The idea that one can go to the IANA web pages, look for an
unused  number, and then assume IANA will assign it a year later is
really bad. What happens when 3 different sets of people do this and
chose the same number? And the IANA (which knows nothing of the three
uses) assigns the same value for an RFC that is just being issued?

This section is also in the wrong format for an RFC. First, IANA
should review this section and report back whether they are able and
willing to make the assignments as requested (they may not be able
to). If they can, the text should simply state things like "IANA has
assigned", as opposed to "IANA SHOULD assign". I.e, think about what
the document should read like as an RFC.

>    The well-known UDP port number 699 used for the Registration Request 
>    and Registration Update Message was chosen from the unassigned port 
>    range. They were requested from and have been assigned by IANA and 
>    are listed at: ftp://ftp.isi.edu/in-notes/iana/assignments/port-
>    numbers. 

The IANA page says 699 belongs to:

accessnetwork   699/tcp    Access Network
accessnetwork   699/udp    Access Network
#                          Yingchun Xu <[email-masked]>

Somewhat surprisingly, the document doesn't use the term "access
network". IANA should update the web page (presumably) to reference
this document. Also, would it make sense to mention the name
"accessnetwork" in the document, or to change this to something like
"cdma2000
access network?"

It would be good in the IANA considerations section to
point out that "IANA has assigned port 699 for the purposed described
in this document" (or something like that). That will ensure that IANA
updates its web page when the RFC gets issues to point to the RFC.

Also, there is a question/comment in regards to the Registration
Reply/Update and Acknowledge secion.  The question arose as to what
happens when a reply/update/acknowledge is expected but not received?
(Is the specified elsewhere?  mobileip?) Since this document isn't
*really* MIP, but a separate protocol, it would seem like it needs to
say when retransmissions are needed, etc.