RE: CTP Last Call Comments

Hi James,

Thanks for the comments. In the future, could you not make page references, but
refence text?  It is confusing working with nroff text, as there are no page numbers
...

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

I'll revise, resubmit before Monday, then we should discuss what to do.

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

Got it.

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

Got it.

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

Got it.

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

I made it an 'A' flag with the correct definition under the message structure.

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

Agreed, I've deleted the text.

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

I hope Charlie can update this text.

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

I added this to the terminology section.
 
> 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)".

Well, I actually think that this should not be sent unprotected, so I have
added text saying that when the key is present, it MUST be protected.

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

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

Sounds good to me.
 
> 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

Done

> (anyway, this is an experimental doc, so why do we need normative and
> non-normative references?). 

I've been asked by IESG members to seperate references for INFO docs, based
on the assumption that someone may need to know which references are
required to really understand the document.

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

done

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

done.


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

James, I agree with your assessment of congestion control to a point, but
what I think we are trying to say is that CTP should not add to the burden,
as the messages should be small.  Reuse of existing transport connections
should remove any latency issues.

> Also, if SCTP is used, there is no issue with latency due
> to retransmits for reliability. 

SCTP still retransmits upto 4 times.  This will cause a problem with
latency.  What we really want to do is set a timer so that if a message
is not recieved within a set amount of time, we can assume that it is
lost.  

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

I will take your suggestion and delete it.

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

Done.

> Also: "In addtion, any application-specific...." -> "Any application
> specific..."
>
> pg. 21 "moderately utilized" -> "heavily utilized"

Done

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

Done, with typos corrected.

thanks,
John