Last Call Review of draft-ietf-manet-dlep-25

Matt Miller <> Mon, 28 November 2016 16:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A24E129E79; Mon, 28 Nov 2016 08:58:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -16.019
X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X-Aao7H72M-H; Mon, 28 Nov 2016 08:58:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 596B61295E0; Mon, 28 Nov 2016 08:58:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4233; q=dns/txt; s=iport; t=1480352298; x=1481561898; h=to:cc:from:subject:message-id:date:mime-version; bh=wrHDOi+qCsxa9tUvd+1wQv4rCJXDx3M3uxR+5ipCxU4=; b=MKH8xihAVlbXluL/2Dl80QgzJhlyI0J9NsErkw/VCy2G1ZZ6Gp28A/k5 Xb4twXS5XRGz93/T1MchnlcZLoVObmQotnX6rwjfiJTqHJNAprgOZNOft 2MhDVRg3dK8EL34lK8sgJ1+4wPXzgu2zMSTZXisW8g4jSPtJxn4yOZVQF Y=;
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.31,564,1473120000"; d="asc'?scan'208";a="353043005"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Nov 2016 16:58:17 +0000
Received: from [] ([]) by (8.14.5/8.14.5) with ESMTP id uASGwHsA010078; Mon, 28 Nov 2016 16:58:17 GMT
From: Matt Miller <>
Subject: Last Call Review of draft-ietf-manet-dlep-25
Message-ID: <>
Date: Mon, 28 Nov 2016 09:58:21 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="hJgBwJrSrmOpa8NrlDaDOUrdixXmiO40q"
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Nov 2016 16:58:20 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

< >.

Document: draft-ietf-manet-dlep-25
Reviewer: Matthew A. Miller
Review Date: 2016-11-28
IETF LC End Date: 2016-11-28
IESG Telechat date: 2016-12-15


This document is almost ready to publish as a Standards Track
document, but has one major issue that should be resolved, and
some minor issues that may need to be discussed.

Major issues:

* The IANA registries this document establishes are not defined.
One can deduce the required information and its format, but there
is no guidance on review process (for example). I urge the authors
to consult RFC 5226 when revisiting the IANA considerations.

Minor issues:

* I wonder if any consideration was made to use TLS for at least
confidentiality when exchanging DLEP Messages.  I can see where
DTLS might not be practicable -- or even possible -- for the
Discovery Signals.  However, the session lifecycle for DLEP
Messages makes TLS a better fit.

* In the heartbeats state description (Section 5.3.), it's not
clear that implementations can factor in other received messages
in determining when to send heartbeats.  From looking at Appendix
B.7 it's clear that was at least considered, but the text makes no
mention.  I think it would be worth expanding on heartbeats to at
least hint at this optimization.

* In the session termination state description (Section 5.4.),
it does not explicitly allow for an unresponsive peer; it states
that an implementation entering this state "MUST wait for a
Session Termination Response Message (Section 10.10) from its
peer", then later hints that an implementation should enter the
Session Reset state when the response is received or it times out.
I suggest that the MUST here explicitly allow for this timeout.

* There seems to be a discrepancy between Section 5.3. "Heartbeats"
and Section 5.4. "Session Termination" with regards to the minimum
number of missed heartbeats before a session should terminate from
no response -- 2 messages versus 4 messages, respectively.  I
suggest putting the minimum limit in either Heartbeats or Session
Termination and removing it from the other.

Nits/editorial comments:

* In Section 3.1. "Requirements", the mandate to use RFC5082 is
said twice -- more generally to all of DLEP in the third paragraph
and then specifically to TCP usage in the fifth paragraph.

* In Section 6. "Transaction Model", the term "destination up" is
not capitalized as it is elsewhere.

- m&m

Matt Miller
Cisco Systems, Inc.