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

From: Rick Taylor <[email-masked]>
Date: Tue, 8 Mar 2016 17:45:31 +0000

More comments to Chris' review inline...

On 02/12/15 15:45, Dearlove, Christopher (UK) wrote:
> 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.

We have reworked this language into 'DLEP participant' and 'DLEP peer' 
using the later when discussing message sending to the other end of a 
session, and the former as a more general term.

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

We now say TCP

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

This sentence has gone in the latest draft

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

We have simplified this restriction to say 'unused port' - this is 
common with most TCP client connections.

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

This has been reworded.

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

The transaction model has moved after this section, and so it should be 
clearer now.

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

I really tried this, but it just looked horrid.  Having recently 
rewritten the heartbeats text, I could be convinced to revisit...

>
> Not sure why jitter is recommended.

It isn't any more.

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

This text has gone.

>
> Same paragraph, should origin address be source address?

Yes - fixed.

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

The counter argument is why MUST they stop?

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

Yes, badly, hence we have rewritten.

>
> 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?

Parsing has been almost universally purged.

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

i.e. has gone (the paragraph has moved in draft-20)

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

Does the same as it's following the same rules.

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

Less SHOULDs, more MUSTs now.

>
> Section 5.4 Odd mixture of heartbeat time lengths and seconds.

Gone in draft-20

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

Because they are not required when the session is closing and they get 
in the way.

On to the next mail...

Rick