Reviewer: Joerg Ott Review result: Ready with Issues Hi, this document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. The draft defines extensions to Proxy Mobile IPv6 to support a more distributed variant of mobility management. In essence, as a mobile node moves from one point of attachment (Mobility Anchor and Access Router, MAAR) to the next, its routing prefix with the previous MAAR(s) remain(s) and ongoing transport layer connections remain active and routed indirectly via the previous MAAR, while new ones will use the present MAAR. The interactions of MAARs are managed via a Central Mobility Database (CMD). The draft is well written and good to follow, describing the protocols and extensions clearly. I just have two transport-specific concern and two general operational issues that require further clarification in the draft. The transport issues: T1. Section 3.2. When the CMD acts as a relay for Proxy Binding Updates (PBUs) and Proxy Binding Acts (PBAs), the CMD may act as a relay of a single PBU to multiple previous MAARs. If multiple previous MAARs exist, say k, (and there may be numerous in case of many fast handovers, e.g., with vehicular networks), the CMD creates k outgoing packets from a single incoming packet. This bears a certain amplification risk (which may also need to be addressed in the security considerations section) but it also may lead to packet bursts originated from the CMD, albeit to different targets. Other protocols start introducing pacing to avoid bursts on the outgoing link, even if the packets do take different paths in the end. This may be worthwhile considering. T2. Also in section 3.2, when relaying PBAs, the CMD serves as a transport or application endpoint and should have a way to deal with missing responses (after all, this is a connectionless protocol on top of an unreliable Internet). A timeout is only mentioned for aggregation, but even there there the timeout is not specified, nor is a reference to, e.g., RFC 5213 or so to infer a timeout used elsewhere. General issues: G1. Section 3.2 (again) specifies that responses are aggregated on p.10. How does response aggregation work? How is error handling done? Moreover, also on p.10, further below the draft states that if a timer expires, the requests already received are forwarded. The missing ones come later. This seems to contradict aggregation because the originator (the currently server MAAR) does not expect more than a single response if it sent out a single update. This may thus require updated processing in the MAAR. G2. Sect. 3.3 suggests that PBAs could be sent straight from the previous MAAR to the current MAAR. How does this work if security associations are supposed to be applied? It would seem that, when following the security considerations, such cases are not covered. At least, this would warrant further explanation as in this case we suddenly have three involved security associations, which would also need to be established. G3. Sect 3.5 discusses deregistration and suggests that this can only be done by timeout; I understand the rationale but can any risks arise on continued resource consumption (DoS attacks)? G4. Sect. 6.: As alluded to above, the security considerations may need expanding. Nits: p.12: "information are" -> "information is" p.12: "influence on" -> "influence"
