Subject: [manet] DLEP-17 review, part 2

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 2 Dec 2015 15:45:39 +0000

Just section 5 this time.

First paragraph. Peer is a new term, and not explained. Here it means modem or router. But later when implementation is being used for modem or router (and I don't like that usage, for me implementation is about a specific realisation of the protocol) peer is being used for the other device (modem/router when this device - the implementation - is router/modem). I think some work on this terminology is needed.

Section 5 before section 5.1 (what I often find convenient to call section 5.0) last paragraph, these are, I think, TCP ports. (I don't think used for UDP, but should be indicated.) It's not clear why we might want multiple ports.

Section 5.0, final paragraph, the address/port combination should be (say that it is) one the modem can be reached and received on.

Section 5.1. Why unused port? Why not the DLEP port? At least as an option. And RFC 6335 calls these (49152+) "Dynamic Ports, also known as the Private or Ephemeral Ports" not unused ports.

I know there's discussion over IPv6 and IPv4 and broadcast addresses, so I'll not comment further. Except to say as written I think it says not only that IPv6 must be implemented, but that you must send IPv6 in all cases.

Section 5.1 second paragraph. This waiting and resending is not the transaction model described in Section 4.1. I'm guessing that's because the latter is only intended in the TCP states. But this should be clearer.

Apart from previous comment on "three (3)" style, I think that it would be better if named parameters were used, with later recommended values. And if there are several values, useful to know if in a fixed (or recommended) relationship. (Yes, there are some relationships given that way e.g. two times heartbeat.) But this is a style question, not a "right or wrong" thing.

Not sure why jitter is recommended.

Section 5.1 first full paragraph on page 13. Why might more than one address/port combination be used. (I'm actually not quite sure why more than one might be offered, but perhaps it's that the unused port might not be unused in some cases.)

Same paragraph, should origin address be source address?

Section 5.1, penultimate paragraph. It's not clear why these signals might still want to be sent, what the purpose or value is.

Section 5.1 final paragraph. Is this then saying must start the router in Session Initialisation State?

Section 5.2, second paragraph. Parsing is here introduced, but not discussed for previous signals. That I think is one of those things that makes you stop and wonder why. Is it clearer to have a blanket comment about parsing somewhere, and elsewhere just stick to received?

Section 5.3, second paragraph. Not particularly keen on lists that are i.e. (RFC Editor will demand a following comma btw) and finished etc., but it's not actually wrong.

Section 5.3 (or 5.3.0 to be clear) final paragraph. And the peer? (As terminology used here, but see earlier comment.)

Section 5.3.1 first two paragraphs have a MAY a MUST and a SHOULD. I can only make these even consistent by assuming that the latter two are MUST/SHOULD in the case where the MAY is so, otherwise not. This could be clearer. (Also worth considering if it's a good mix.)

Section 5.4 Odd mixture of heartbeat time lengths and seconds.

Section 5.4 pre-penultimate paragraph, Destination Down messages MUST NOT be sent. Why that specific case (only)?

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