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

From: Rick Taylor <[email-masked]>
Date: Tue, 8 Mar 2016 18:23:18 +0000

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

Signals and Messages have been split properly in draft-20.

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

Yes, fixed.

>
> 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, and should be 4 digit.

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

'contained in' is described as the correct terminology earlier and is 
now used.

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

Now says MUST

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

Now says 'zero or more'

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

This has been rewritten and expanded to clarify in draft-20

>
> Section 8.2, similar comments to Section 8.1.

See above

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

Fixed by rewording

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

The major change for draft-20 is to do this.  We now have 'introduction' 
'construction' 'usage' fairly consistently.

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

It was, and it has!

>
> Section 9.0 paragraph 1, last line, is “this header” (singular) correct?

This paragraph has gone, it was confusing.

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

Hmm... don't know what else to put there, we await suggestions.

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

They don't in draft-20

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

Yes, fixed.

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

This remains, but hopefully the other fixes makes it acceptable now?

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

It's a MUST now.

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

Singulars have been rewritten.  I'm not sure what the right way to go 
with the 'each'/'any' issue.

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

Yes I believe so.

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

Good catch!

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

It's a MUST now.

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

This has been heavily reworked in draft-20, but this paragraph remains. 
  Can you revisit?

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

We haven't gone the whole way to define an Information Base, but the 
re-ordering in draft-20 might make it clearer.

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

Fixed.

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

This has been reworked in draft-20.  Status codes now have a proper section.

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

Great care is no longer necessary.  Heartbeats are mandatory in draft-20.

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

What has gone, and so has the MAC address only Link C Request (in -20)

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

Hmmm... hyperlinking has gone awry.

And on to part 6...

Rick