Subject: [manet] DLEP-17 comments, part 5

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 4 Dec 2015 12:31:09 +0000

This is Sections 8 and 9. Still to go, Section 10 and appendices.

Section 8. At this point I wondered if the signal/message separation (which I haven't respected in all my previous comments) was properly foreshadowed. And it isn't. Section 4 uses both in its subject line, but then never describes the difference. Consider this a comment on section 4 I missed earlier.

Section 8.0 penultimate paragraph, should this be more clearly the acceptability of duplicate data items?

Section 8.1 I'm not familiar with the U+44 syntax (for UTC-8 I assume). Is it well-known to be hex?

Section 8.1 Length. Part of, rather than associated with.

Section 8.1 and elsewhere use SHALL for length restrictions. I know 2119 equates SHALL and MUST, but everywhere else is MUST, is there a reason for SHALL here?

Section 8.1 (and I think also for messages) says one or more data items. That must be zero or more, there are several cases where zero is permitted, and at least one where it is required (heartbeat).

Section 8.1 in the list of reasons to reject, a missing required data item isn't listed, and as well as an unrecognised data item, should have not appropriate to this signal. (And the same is probably said again for messages - the duplication makes me wonder if the separation loses more than it gains.)

Section 8.2, similar comments to Section 8.1.

Section 8.3, Length. value should probably be Value. And the term header hasn't been defined for a data item.

I would prefer a separation of the signal/message/data item syntax from the behaviour. Admittedly there are a couple of corner cases (how to handle a missing Status - though that itself is a bit ugly). But for example section 9.5 (probably the worst case) starts with behaviour, has an aside (which I'll come back to), then more behaviour, then syntax, then some behaviour again.

Yes, that would be significant work to restructure, and it's not my call to say it should be done. But it would (in my opinion) make for a better document.

Section 9.0 paragraph 1, last line, is "this header" (singular) correct?

Section 9.0 second paragraph "Following is" is wording I'd make a guess the RFC Editor will change if still there. (Based on the last few RFC Editor responses I've had, they are changing quite a bit of wordings they don't like, more than they used to.)

Table 1. Apart from the IANA issue I raised in last part of my comments, why do signal and message types share a single space?

Table 1, previously noted Reserved is incorrect usage (17+)

Section 9.1 At this point with SHOULD, I'm left asking what if not? That I assume is because of the preconfiguration option discussed in an earlier section. But doesn't say so, and is part of the it would be clearer to separate data from process.

Section 9.1 MAY implement own heuristics. This I think goes all the way to MUST, not even SHOULD. OK, possibly the heuristic is "don't bother", but you still need to decide that and decide it's acceptable.

Section 9.2 . Later lists use an "each of the following data items" even when singular. I have no idea whether the RFC Editor will accept that. But here before the first list singular is used, and the second list uses "any" rather than "each".

Section 9.2 the discussion of ports in the IP connection (or well-known if none) is this consistent with the use of the (not strictly correctly named) unused port in earlier sections? I haven't worked this through.

Section 9.3 last line on page 22 "the" before "Session" (I happened to notice this one).

Section 9.3 first line on page 23. "should" probably should be SHOULD, except I think it actually should be MUST (see above, where it's MAY, so inconsistent in any case).

Section 9.5. The whole concept of router signalling modem should be brought out earlier in the document. The paragraph starting "Concerning layer 3 addresses" is a particularly jarring one in the mixture of protocol and data.

Section 9.5 (and elsewhere) information base. I don't think this is discussed in the introduction. While a mandatory information base format may not be right, a discussion of what data is collected - and what needs to be persistent (such as list of extensions being used) I think would be appropriate.

Section 9.5 (and elsewhere) when indicating IPb4/IPv6 addresses "one or more of the following" is not clear, suggest "one or more of each of the following" (which fits other pattern).

Section 9.7. This is one case of non-success defauilt Status. But here in particular, no reference to where that status is found.

Section 9.14. paragraph three "Great care ... " Is a 2119 MUST appropriate here? I'm not sure this sentence helps the implementer. Why? How?

Section 9.15 paragraph 2 "what is" I'd delete the "what". Not sure about capitalised ONLY. And "partner" is a new term that shouldn't be used.

Section 9.16 Table 3 is here referenced. Apart from the IANA issue, there's also no indication where that is.

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 04 Dec 2015 16:45:09 +0100

> Section 8.1 I’m not familiar with the U+44 syntax (for UTC-8 I assume). Is
> it well-known to be hex?

Yes, but it requires 4 hex digits -- it should say U+0044.

-- Juliusz