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

From: Justin Dean <[email-masked]>
Date: Mon, 8 Jan 2018 16:46:48 -0500

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

---

From: Victoria Pritchard <[email-masked]>
Date: Sun, 21 Jan 2018 18:03:43 +0000

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 <[email-masked]> wrote:

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>

---

From: Victoria Pritchard <[email-masked]>
Date: Sun, 21 Jan 2018 19:24:58 +0000

Hi all,

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

Abstract

Section 1

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 <[email-masked]>
wrote:

> Is it " Latency Range Item " or " Latency Range Data Item "? Makes sense
> to be consistent
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 25 Jan 2018 18:50:50 -0500

Vicky,

     Thank you for the comments!

> Just a few picky comments on the Latency Range draft.
thanks.

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

Well that's embarrassing! Fixed in all extensions.

> "provides an average latency" - the definition in RFC8175 actually 
> says "The calculation
>    be a running average calculated from the internal queuing." so not 
> sure it's right to say it provides an average.
>
how about:
    The base DLEP specification includes the Latency metric which provides
-  an average latency on a link.  This document adds the ability to relay
+  a single latency value on a link, which is implementation dependent.
+  This document adds the ability to relay

> Is it " Latency Range Item " or " Latency Range Data Item "? Makes 
> sense to be consistent
>
agreed.

> Similar comment for Minimum Latency
thanks!

> "Data Item Type Values"  is the name of the registry in RFC8175.
fixed in all drafts!

> Vicky

Thank you - changes have been pushed to the repo...

> On 8 January 2018 at 21:46, Justin Dean <[email-masked] 
> <mailto:[email-masked]>> 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>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/manet>
>
>
>
>

---

From: Victoria Pritchard <[email-masked]>
Date: Fri, 26 Jan 2018 04:36:11 +0000

Hi Lou,

Thanks for the response...

On 25 Jan 2018 23:50, "Lou Berger" <[email-masked]> wrote:

Vicky,

Abstract

I think DLEP itself was confused for a little while too ;)

Looks good to me

"one new DLEP

Section 5.2

Brilliant :) thanks Lou.

On 8 January 2018 at 21:46, Justin Dean <[email-masked] <mailto:
> [email-masked]>> wrote:
>