Document: draft-ietf-ospf-manet-or-01 Reviewer: Ben Campbell Review Date: 2008-12-23 IETF LC End Date: 2008-12-24 IESG Telechat date: (if known) Summary: This draft is almost ready for publication as an experimental RFC. I have a few questions/comments, and a few nits, that should be considered prior to publication. Substantive Comments/Questions: -- Section 3.1.1, last paragraph: Why is this a SHOULD and not a MUST? Does anything break if it is not followed? -- Section 3.2.8:, paragraph 2: How do you identify a wrap around? I can infer how, but better to be explicit. -- Section 3.3.2. paragraph 3: "Each speaker SHOULD select..." SHOULD use a selection algorithm is vague without some statement of the properties of the algorithm. You list an example. Are you saying that the speaker SHOULD select an alogorithm with properties similar to the example? (I see that you commented on this in section 3.3.4, but it is confusing not to find the answer nearer to the normative requirement in this section. I suggest moving or replicating that statement to this section.) -- section 3.3.4, last paragraph: Is the requirement for all nodes in an area to use the same algorithm a problem, if the algorithms are implementation specific? Are different implementations not expected to interoperate? Do they need to negotiate the algorithm selection? -- Section 4: Is the lack of any existing mechanism to authenticate and authorize nodes to transit packets a show stopper for deployment? If this was standards track, I would want to see a lot more here, e.g. some exposition of threat models implied by the wirelessness, or introduced by the extensions and procedures described in this draft. (Or rational that there are not any new threat models) It's probably okay for an experimental RFC to have less, as I assume we expect to learn such things from experience. But if any thinking has been done in that direction, it would be beneficial to document it now. Nits and editorial comments: -- Don't forget new boilerplate (I know the boilerplate situation is messed up, so I don't know how to proceed on this one. I mention it for completeness.) -- Outdated reference to draft-ietf-ospf-lls-05. Version 06 is out as of now. -- The draft has lots of references to other internal sections by title only. This creates extra work for the reader to follow the references. It would be helpful to include the section numbers in such references. -- Section 3.1, paragraph 2: It's not clear to me if the "MAY" constrains protocol, or constrains future standards work. If the second, it probably should not use 2119 language. -- Section 3.3: Redundant "only" in 2nd sentence. -- Section 3.3.10: PushBackInterval Referring sections mention PushbackInterval + jitter. Jitter is not mentioned here--is propagation delay the same thing in this context? If so, it would be helpful to be consistent in terminology. -- Section 3.5.3, paragraph 1: s/defined synchronized/defined to be synchronized ; or "defined as synchronized" -- Section 5, LD Options registry creation:"... require IETF standards action" Does that require them to be documented in standards-track RFCs? If so, I must point out that _this_ draft is experimental.