CTP Last Call Comments

I've seen no comments on CTP. Here's mine. Unfortunately, this document is
not ready to go to the IESG.

            jak

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

pg. 5 last paragraph: There's some kind of formatting botch here: "[1].*
contexts." etc.

pg. 8 second paragaraph: Another formatting botch: "%Notice that the length
of the % the context data block", etc.

pg 8, generic header diagram. I thought we agreed to remove the generic
header diagram? It doesn't apply to all messages and is just confusing.

pg. 9 top. An 'A' flag is mentioned, but none appears in the message. I
think you mean 'R'. Also, in the description of the 'R' flag, it should
indicate what reliable transfer means or point to a section in the document
that describes this. Later in the document, we learn that this means
partially that an acknowledgement is requested. Anything else?  That should
be here. If there's nothing else, I would call it "Acknowledged" transfer to
avoid confusion with transport reliability, and I would, in fact, make it an
A flag.

pg. 11 top. Why does this draft say something about proxy address defense?
CTP has nothing to do with routing. That should be for the protocol that
does local routing repair (i.e. FMIP). If something needs to be said about
address defense, mention  can be made to the role of the handover protocol
in that.

pg. 10 middle. The calculation of the authentication token is not easy to
follow. It should be broken out of the text body. Also, what secret is
referred to in the 2nd line? Either point to the section where it is located
or indicate here what it is. In fact, I would not call it a secret since, as
we learn later on in the document, it is send over an unsecured channel. I
would say that it is "a nounce exchanged between the AR and MN over an
unsecured channel that is used for identifying the MN and is valid for a
limited duration, on the order of a few hundred milliseconds".

pg. 11 middle: What do the initials "PCTD only" mean? We learn in the
paragraph afterwards that predictive context transfer requires these. These
initials should be referenced in this paragraph.

pg. 11 A key is being sent here, but the packet is not protected. Is this
wise? Something needs to be said here about why not, or a pointer to a
discussion in the security considerations section. This is likely to be a
red flag for the Security ADs. If there is no protection on the packet, then
I would suggest calling it something other than a shared secret or key,
perhaps an "authentication nounce that is difficult to spoof but not
designed to be highly secure because the duration of validity is so short
(on the order of a few hundred milliseconds)".

pg. 12 last paragraph "Sent by nAR to pAR request" -> "Sent by nAR to pAR to
request"

pg. 15 I'd like the following paragraph inserted right after the section
header for Section 6 (Security Considerations);

    At this time, the threats
    to IP handover in general and context transfer in
    particular are incompletely understood, particularly
    on the MN to AR link, and mechanisms
    for countering them are not well defined. Part of the
    experimental task in preparing CTP for eventual
    standards track will be to better characterize threats
    to context transfer and design specific mechanisms to
    counter them. This section provides some general guidelines about
    security based on discussions among the Design Team
    and Working Group members.

The issue of security came up in the discussion of MIPSHOP chartering, and I
want to make sure that the IESG understands that this section is not
intended to provide a thorough discussion of CTP security.

pg. 18. The referenences are out of date. [CT-REQ] should be dropped, this
document has been dropped by the WG.
[FMIPv6] and [LLMIP] should be moved to the non-normative references as they
are only referred to in the appendix and appendicies are not normative
(anyway, this is an experimental doc, so why do we need normative and
non-normative references?). RFC2434 reference is not properly formatted.
[CTHC] can be removed, there is an example in this document now. If there is
no reference to [RFC2401] please remove it, also [RFC2246].

pg. 19. 3rd para in Apx. A. Drop the reference to BETH. The rest of the para
is OK.

pg. 20 Recent IAB work with Sally Floyd and discussion with lots of people
including some ISPs around the issue of congestion for VoIP traffic has
identified access networks as precisely the place where congestion *is*
likely to occur. Core networks are typically massively overprovisioned and
therefore never suffer congestion. So I don't agree with this analysis. I
also don't agree that using a congestion controlled TCP or SCTP connection
is such a burden. The routers in the access network won't start the
connection on the fly, they would have a connection open to all routers in
their geographical vicinity and reuse it, as a result, there should be no
startup transient. Also, if SCTP is used, there is no issue with latency due
to retransmits for reliability. DCCP could also be used, though it is
primarily intented for media. Of course, if context is dropped due to
congestion the handover optimization will fail, but that is another issue. I
believe this section is likely to receive intensive IESG criticism.
Something could be said about this issue being for further study.
Alternatively (and in my opinion, a better choices) is to remove the
section.

pg. 20 Please remove the pseudo section headers from Appendix C or use
section numbering (e.g. C.1, C.2, etc.).

Also: "In addtion, any application-specific...." -> "Any application
specific..."

pg. 21 "moderately utilized" -> "heavily utilized"

pg. 21. The section on MLD state machine interactions is somewhat hard to
read (yes, I know I wrote it). I'd suggest the following rewrite:

    No changes are requried in the MLD state machine.

    Upon receipt of a CTP Context Data Block for MLD, the state machne takes
the following actions:

        - If the router is in the No Listeners present state on the wireless
interface on which the Subnet Prefix field from
           the Context Data Block is advertised, it transitions into the
Listeners Present state for the
           Subscribed IPv6 Multicast Address field in the Context Data
Block. This transition is exactly
           the same as if the router had received a Report message.

        - If the router is in the Listeners present state on that interface,
it remains in that state but restarts
          the timer, as if it had received a Report message.

    If more than one MLD router is on the link, a router receiving an MLD
Context Data Block SHOULD
    send the block to the other routers on the link. The router MAY instead
send a proxy MLD Report
    message on the wireless interface which advertises the Subnet Prefix
field from the Context Data Block
    if wireless bandwidth is not an issue. Since MLD routers do not keep
track of which nodes are listening to
    munticast addresses, only whether a particular multicast address is
being listened to, proxying the
   subscription should cause no difficulty.