Summary: This draft is on the right track but has open issues, described in the review. [I actually wanted something between that and the next worse one. -MAP] Summary ------- I _think_ the described protocol is basically OK, but had enough trouble understanding many parts of the document that I can't be certain. Given the problems I had (and I was just trying to _understand_ it, not implement it), I think the document needs at least one more major editing cycle before publication. I did find a couple of technical problems, but don't think they should stop the effort as I think they can all be addressed without redesign. But, unless I misunderstood (possible given the other problems), I don't think this document can go forward without addressing them. General comments ---------------- I don't think the operation with a routing protocol has been well thought out. It certainly hasn't been well integrated into the document as evidenced by the fact that it's mentioned in a few places in the main document (all of which have problems as described below) and mostly relegated to to a separate section (which also has problems). While I can intuitively see how Mobile Routers on Mobile Networks behind other Mobile Routers will work, the explanation is probably too terse for someone less familiar with such types of operation. [I have something like this at home, although the "Mobile Routers" are not actually "moving" in my case.] Technical Problems ------------------ In at least two places they have a requirement that a mobile router that advertises it's network when at home must never advertise this prefix on a visited network. This is a requirement which cannot, in practice, be met in all cases. A periodic routing packet could be sent in the interval between when the connectivity changes and the router discovers that fact (think atmospheric effects on radio transmission, or an Ethernet switch having the VLAN allocations changed). In section 6.6 under a certain condition (which is independent of whether implicit or explicit mode is in use) it describes sending error status code 140. However, in the description of what a MR does with responses in explicit mode, error code 140 implies discard response. If the MR is going to discard it, why send it? The MR needs to know there was a problem, so I think the fix is to make it process these. Other problems with the document -------------------------------- Both sections 5.2 and 6.2 talk about only implicit and explicit modes of operation and ignore dynamic routing. This case needs to be covered in these sections as well. In some places it says a success is indicated by a status code of 0 while in others it says any code from 0-127 is success. It needs to get that right everywhere. Section 5.4 has a lot of wording problems, not the least of which is the frequent use of the word "should" in lower case. I'm not sure if they want them to be SHOULD, if not I advise use of a different word, and if so, fix it. In the second paragraph of 5.5 they talk about the single bi-directional tunnel and two simplex tunnels. They need to get their terminology straight. The second one of the ticked items in 6.2 (i.e. the second indented thing with a "-" in front) I just didn't get. I read it several times, took a break, came back and read it several more times. After that, it still wasn't clear to me what it was doing there. My understanding of the words always resulted in either a tautology or a non-sequitur, neither of which could have been their intent. In the third paragraph under section 5, the wording is quite strange. I'm not sure what they are doing without more research than I have time for, but my guess is that they are saying at the end that under a specific set of criteria, they are relaxing a MUST in another document to a MAY, but they need to be clearer on the intent. In section 8 they describe a requirement for confidentiality (and there may be confidentiality aspects to other parts of the operation), but there is no mention of confidentiality in the "Security Considerations". I think there are other things that need to be in there, too, but leave more detailed critique to the Security Area. There are two sections titled "References", neither of which has a section number or appears in the TOC. My first guess was that one was supposed to be normative and the other informative, but if that's so they have several references misfiled (5 is info not norm, 8&9 are norm). I found it strange that several of the message format diagrams started in the middle of a word. A naive implementer might think that meant there were 16 unused bits. This is, however, consistent with reference 1 (the protocol it extends), so I guess it's OK. In several places they talk about operation in the various modes, but never really say how a node decides which. I realize that the intent is that it's locally configured in the MR, but I think it deserves being explicitly said somewhere. Section 3 (Overview) is too long to be a single flat section. Either it needs a lot of careful word-smithing to tighten it up, or it needs subsection headings to help organize it. It really is hierarchical, but without section headings I found myself lost once or twice until I realized we were back at the next higher level concept. Also, I saw dozens of typographical and formatting errors that I didn't have time to note...