[manet] Comments on DYMO-09

["Dearlove, Christopher \(UK\)" <Chris.Dearlove at baesystems.com>]

I made these as ink on a paper copy without an
electronic copy, so apologies if I missed something
where I suggest some thing is missing. I've ignored
typos (not that there are many I spotted).

What I haven't followed through is some of the
details of things like (in particular) comparison
of information for which is better.

- The example message pictures are based on out of
  date packetbb - and not just not based on the one
  in the IETF secretariat queue. But I'm afraid I
  haven't worked out a correct version. Of particular
  note is the changed message and TLV semantics and
  the new(-ish) address block semantics.

- On reading the overview my first though is "that
  doesn't work, it assumes bidirectionality". While
  the overview isn't the place to spell out a mechanism
  to only use bidirectional links, I think it needs to
  make the point there's an issue and refer forwards.
  Actually what it refers forwards to is an issue, but
  that's a later point below.

- To make DYMO work, you need three things that OLSRv2,
  for example, doesn't need (though if it had them it
  could make use of them, especially the last): how to
  know that a route is needed, how to know a route is
  still in use, what to do with packets while waiting to
  find a route. I think at the least these need to be
  spelled out, even if only to say they aren't part of
  DYMO as such. (Of course if these are suggestions,
  e.g. ARP failures, or if you know whose problem they
  are - IP for packet queuing? - these are good comments.)
  These seem to me to belong in Section 2.

- On the rest of Section 2, can you go beyond stub networks
  (is this a necessary limitation? - I'm not saying it's not,
  I'm just not wanting you to underclaim). Also the little
  routing state comment is dependent on the earlier limited
  communications poin - and if you do too much path accumulation
  etc. you can blow it even then. And it's "some" other routing
  protocols I think - is DYMO much better than DSR (or AODV, but
  DYMO is really AODVv2). In the last sentence I'd remove the ()
  as the words in it are fundamental - you really don't want to
  suggest it's true with the whole parenthesis removed!

- I wondered if the terminology would be better if under RERR
  etc. it explicitlty said "a message type". (That's a definite
  "take it or leave it" comment.)

- In 4.2.1 the brief description must be improved by noting that
  DYMO doesn't need a packet header. But maybe it does, see a
  later comment. (If it does, that's a comment.)

- UDP port TBD hasn't caught up with draft-iana. (Several places.)

- When you say IP TTL (IP Hop Limit) I'd insert a v4 and v6.

- Final line of 4.2.1. There are two mechanisms in RFC 4291,
  one is deprecated. We just added to packetbb an extra phrase
  indicating which one to use in our similar paragraph. It
  might keep some people happier.

- Sequence numbers. If I understand correctly, you start at 1,
  then when you get to 65535, skip 0 (as it's special) but then
  go to 256, not 1. I can't see anything saying why, nor do I
  understand why. (It makes the 16 bit comparison a bit lop-sided,
  but frankly if you are comparing numbers 30,000 apart there's
  a problem anyway.)

- 5.3.1 just mentions expanding ring search, and refers to AODV
  for details. Can you (IETF procedure here) delegate details of
  your Standards Track protocol to an Experimental RFC? I'm also
  (section 5.4) not sure the exponential backoff is quite as
  detailed as I would have suggested. But this might not matter
  if it's not interoperability critical.

- 5.3.3 uses gratuitous RREP. Suggest adding that to the terminology.

- Later (5.3.4 made me think of it, but it's not specific to there)
  I wondered does DYMO do network aggregation? What happens if I have
  a route to A.B.0.0/16 and I get a more, or less, up to date route
  to A.B.C.0/24? Or the other way round? Would it matter if they
  had the same next hop? Or are those two routes treated as chalk
  and cheese and never compared? (I was wondering about the state
  minimisation and if this helped.)

- Last paragraph of 5.4 refers to "the buffer". This ties in with
  comments on Section 2. Whose buffer? Can we rely on IP doing this?
  What about that buffering is a two-edged sword, it can really mess
  up TCP, for example. (The buffer may be seconds long I think.)

- Section 5.5. This might be another issue for Section 2, that
  DYMO needs to be able to manage ICMP.

- Section 5.5.1. Interaction of DYMO and NHDP is potentially
  interesting. If you just want to manage links (and that they
  are symmetric even) you only need a subset of NHDP. With all
  of NHDP you could add MPRs (which aren't in NHDP but in OLSRv2)
  and start optimised flooding. But that's not as reactive as
  you might like - and there's an interoperability issue (everyone
  needs to do it - I think). But the point is NHDP is likley to be
  too much or too little, but not exactly right. (For the "too much"
  case we could probably work out some words as to what to exclude.
  Multiple interface issues might matter.)

- Section 6. Do you need exponential backoff and expanding ring
  parameters?

- Section 7. Need to discuss subtypes. I suggest using packetbb and
  TimeTLV as models for what needs saying.

- Section 7.2. Have I missed something, or is the text buried in the
  Value discussion of Table 5 of the IANA considerations section the
  only text that discusses the unidirectional link issue? If so that
  really needs to be in the main protocol section, in detail. By being
  a packet TLV it also suggests you need a packet header, which also
  needs saying earlier.

- I didn't follow some of the Security Considerations discussion.
  (I know that doesn't actually help.)

- Section 9 - DSR is now an RFC.

- References - Should draft-iana be normative?

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************



_______________________________________________
manet mailing list
manet at ietf.org
https://www1.ietf.org/mailman/listinfo/manet