Re: [manet] ready for LC : latency and multi-hop

[Victoria Pritchard <[e-mail]>]

Hi all,

Some comments on the multi-hop extension draft...

Abstract
Should you reference the DLEP RFC number here? Or at least expand the
acronym?

Section 1
It's "Dynamic Link Exchange Protocol" (not "Event Protocol")

Throughout the draft, should "data item" be "Data Item"?

Section 3.1
It SHOULD be carried in all those messages - does that mean even if it
hasn't changed since the last time it was reported?

Under Hop Count field description - "used to indicated" - extra 'd' on
"indicated"

"a destination no
      longer being reachable"
So this would be sent in a Destination Announce Response message, even if
there was no Destination Announce to reply to? Is the Destination Announce
Response the reply to the Hop Control action? Also, the destination no
longer being reachable would cause a Destination Down according to core
DLEP rules, right? So two messages get sent?

Section 3.2
"A router can request multi-hop reachable
   destination be changed to a single hop. "
Should that be "request a multi-hop"?

If the Hop Control is sent in a Session Update, this section says the
result is sent in Destination Down or Destination Update messages. Assuming
this means the Hop Count Data Item is used to give the result, Section 3.1
doesn't mention use in Destination Down. Also, on that note - is the
Destination Down allowed to include the Hop Count Data Item (I don't think
RFC8175 forbids this but usually there's only a MAC address data item in
that message)?

If the Hop Control is sent in a Link Characteristics Request message, the
text says the response is another Link Characteristics Request Message
- shouldn't
the response be a Link Characteristics Response Message? Also, not sure
where the Destination Announce Response Message as stated in Section 3.1
fits?

The final 2 sentences in the 4th paragraph - being really picky here, but
"any changes in Hop Counts" would include the hop count becoming zero if
the destination is no longer reachable, so according to this text there
MUST be a Destination Down and there MUST also be a Destination Update?
Could make it say "any other changes in Hop Counts"?

For other destinations that are affected by a link characteristics request,
are the Destination Update and Destination Down messages sent as per core
DLEP, or would they include the Hop Count Data Item indicating that this
change occurred due to a hop control action?

5th paragraph here repeats "Session Update Message" - but then talks about
associated destination MAC - and seems to try to address both session
update and link characteristics, which have been explained in the previous
2 paragraphs. Looks like this has been cut and pasted but since it's
separated into two earlier paragraphs it could probably be removed?

3.2.1
"Session Update Message message" - extra "message" at the end. Same in
3.2.2, 3.2.3.

3.2.2
Why does this request have no impact for multi-hop destinations?

3.2.3
The text about other destinations being impacted applies to all these
actions - and is already explained earlier, so doesn't need to be repeated
here. Later sections say "as described above".

3.2.4
The other actions are "SHOULD" and 2 of them also say "attempt" - why is
this a MUST?

Section 4
Is there meant to be a capital S on Security in the final sentence?

5.2
"Data Item Type Values" rather than "Data Item Values"

5.3
There shouldn't be a full stop after the reference to RFC8126.


Kind regards,
Vicky.

On 21 January 2018 at 18:03, Victoria Pritchard <[e-mail]>
wrote:

> Hi all,
>
> Just a few picky comments on the Latency Range draft.
>
> Title
> Lantency -> Latency
>
> Abstract
> Should you reference the DLEP RFC number here? Or at least expand the
> acronym?
>
> Section 1
> It's "Dynamic Link Exchange Protocol" (not "Event Protocol")
>
> "provides an average latency" - the definition in RFC8175 actually says
> "The calculation
>    of latency is implementation dependent.  For example, the latency may
>    be a running average calculated from the internal queuing." so not sure
> it's right to say it provides an average.
>
> "one new DLEP
>    Data Items" - unnecessary 's' on Items
>
> Section 3
> Is it " Latency Range Item " or " Latency Range Data Item "? Makes sense
> to be consistent
>
> Under the Maximum Latency field description:
> "representing the transmission longest
>       delay"
> should that be "longest transmission delay"?
> Similar comment for Minimum Latency
>
> Section 5.2
> "Data Item Type Values"  is the name of the registry in RFC8175.
>
>
> Regards,
> Vicky
>
> On 8 January 2018 at 21:46, Justin Dean <[e-mail]> wrote:
>
>> As discussed during IETF 100 these documents are now in last call. Please
>> review them and post comments to the list.
>>
>>
>> https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extension-01
>> https://tools.ietf.org/html/draft-ietf-manet-dlep-multi-hop-extension-03
>>
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet
>>
>>
>