[manet] Fwd: New Version Notification for draft-ietf-manet-dlep-latency-extension-05.txt

Lou Berger <lberger@labn.net> Thu, 21 November 2019 03:05 UTC

Return-Path: <lberger@labn.net>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E7B01120924 for <manet@ietfa.amsl.com>; Wed, 20 Nov 2019 19:05:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 21IPJDCPCjMd for <manet@ietfa.amsl.com>; Wed, 20 Nov 2019 19:05:28 -0800 (PST)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC391120925 for <manet@ietf.org>; Wed, 20 Nov 2019 19:05:28 -0800 (PST)
Received: from cmgw11.unifiedlayer.com (unknown []) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id D338C215C2D for <manet@ietf.org>; Wed, 20 Nov 2019 20:05:26 -0700 (MST)
Received: from box313.bluehost.com ([]) by cmsmtp with ESMTP id Xcmci7EXzlpxgXcmcicgIC; Wed, 20 Nov 2019 20:05:26 -0700
X-Authority-Reason: nr=8
X-Authority-Analysis: v=2.3 cv=YKmxNyOx c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=MeAgGD-zjQ4A:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=TIKy-cHXXefNqf74ZtUA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=AEmN_pUa7lWKdVptqWwA:9 a=fo16pW8PTeqZmfQR:21 a=_W_S_7VecoQA:10:nop_html a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:To: References:Subject:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=5pCbeXfT24t7cW+8M76yDPwwj2PYQbaS50Q/WECtKmQ=; b=zFzCz0plaSNOIs7iHFz4xO30uZ 8QdXOwfq+EiziZV54oLhPggA/n8dqIEJD4zTmv0QaFU0SUuF5M6EtTcTArf7gRKwcGEf474vR+WfL jrTUfIE3TdJ4xv968NjiP6Z7V;
Received: from [] (port=41989 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <lberger@labn.net>) id 1iXcmc-001xKe-7B; Wed, 20 Nov 2019 20:05:26 -0700
References: <157424303536.30528.4441271117365525677.idtracker@ietfa.amsl.com>
To: MANET IETF <manet@ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>
From: Lou Berger <lberger@labn.net>
X-Forwarded-Message-Id: <157424303536.30528.4441271117365525677.idtracker@ietfa.amsl.com>
Message-ID: <b88f93ad-f274-6028-2625-dfff12e99844@labn.net>
Date: Thu, 21 Nov 2019 11:05:23 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <157424303536.30528.4441271117365525677.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------01C9CDD15ACB403E4C251EB7"
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-L: Yes
X-Exim-ID: 1iXcmc-001xKe-7B
X-Source-Sender: ([IPv6:::1]) []:41989
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/I8lM4opFAJkceqSgKyU3XsK0uIM>
Subject: [manet] Fwd: New Version Notification for draft-ietf-manet-dlep-latency-extension-05.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Nov 2019 03:05:31 -0000

Hi all,

     This update attempts to address the open issues on the draft.  The 
nits have been addressed, but a couple of comments did not result in 
text changes.  Specifically:

WRT https://mailarchive.ietf.org/arch/msg/manet/ptFmjBUMhhir2Lzu0wv1IfJjezI

> * Regarding "The use of the Latency Range Extension SHOULD be 
> configurable", an
> operational comment: What is the default (enabled or disabled)?
I don't feel strongly about this, but I did not make a change here as 
(a) it isn't really an issue that impacts interop and (b) the WG didn't 
state an opinion on this.
> * In what cases does this not need be configurable (i.e., is it a MUST)?
As I understand it it is a choice and implementation and deployment 
scenario.  I did not change to a MUST as this would be a technical 
change that would need WG input and I personally didn't see it as a 
significant concern.

Of course, I defer to the WG.

> * Error checking: what happens if the Latency data item defined in RFC 
> 8175 falls outside the range of
> the Latency Range data item herein defined?
I spent more time consider this the related comment of the other review 
listed below,  DLEP RC 8175, notably section 6,  does not place an 
restriction on metric values.  I didn't think it appropriate for this 
extension to change this practice/precedent. Some of us discussed adding 
more guidance, e.g., something along the lines of "the receiver 
SHOULD/MAY ignore .. (when there is an inconsistency)..."  but concluded 
that this would (a) not really be meaningful to implementations and (b) 
perhaps more importantly, be consistent with the rest of the metrics 
defined in 8175.

> (i.e., I understand that should not happen but I may be wrong). And 
> what if Latency Range is included without
> Latency being included?

The document does not modify 8175, so the rules on presence and 
processing of the Latency extension remains as specified there.

WRT https://mailarchive.ietf.org/arch/msg/manet/qxJ-AxMEK3cRJucHnM9UimhXrUI

> ** Section 3.  How do the maximum and minimum latency fields relate?  For
> example, what happens if a receiver gets a message where the maximum latency is
> smaller than the minimum latency.

> ** Section 3.  How do the latency data item and the latency range item relate?
> For example, what happens if a receiver gets a message that has both a latency
> data item and a latency range data item, and the reported latency is outside of
> the latency range?

These comments are is similar to the error checking comment above and 
has the same response (and no resulting text change.)  This includes not 
wanting to do something that would be inconsistent with RFC8175 which is 
quite on handling of received metrics.

Please respond/discuss if you think these response are not correct if 
additional changes are needed to the document.

Thank you!
-------- Forwarded Message --------
Subject: 	New Version Notification for 
Date: 	Wed, 20 Nov 2019 01:43:55 -0800
From: 	internet-drafts@ietf.org
To: 	Lou Berger <lberger@labn.net>et>, Bow-Nan Cheng <bcheng@ll.mit.edu>

A new version of I-D, draft-ietf-manet-dlep-latency-extension-05.txt
has been successfully submitted by Lou Berger and posted to the
IETF repository.

Name: draft-ietf-manet-dlep-latency-extension
Revision: 05
Title: Dynamic Link Exchange Protocol (DLEP) Latency Range
Document date: 2019-11-20
Group: manet
Pages: 5

This document defines an extension to the Dynamic Link Exchange
Protocol (DLEP) to provide the range of latency that can be
experienced on a link.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat